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ABSTRACT 


This  thesis  focuses  on  the  development  of  a  data-driven 
decision  support  system  to  assist  the  Egyptian  procurement 
activities  in  foreign  countries.  The  Egyptian  Procurement 
Office  in  Washington  D.C.  (POW)  is.  taken  as  an  example  to 
apply  this  research.  Two  areas  of  procurement  type  have  been 


examined  in  POW,  the  Commercial  Procurement  and  the  Govern¬ 
ment  Procurement  activities,  the  later  type  is  based  on  the 
USA  Foreign  Military  Sales  (FMS)  system.  The  Data  Flow  Diag¬ 
ram  -technique  have  been  used  to  -analyze  the  system.  PC/FOCUS 
have  been  used  to  design  a  prototype  software  for  the  POW 
Commercial  Procurement  subsystem  to  use  in  an  IBM -XT  or  I 3M- 
AT  or  compatible  microcomputers. 
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I.  INTRODUCTION 


A.  OBJECTIVES  OF  THESIS 

The  objectives  of  this  thesis  are  to  analyze  the  current 
procurement  system  of  the  Egyptian  Procurement  Office  in 
Washington  D.C.  (POW)  to  determine: 


1.  Decision  criteria  are  used  to  select  vendors  to 
receive  the  RFP's; 

2.  The  most  effective  way  to  monitor  and  administer 
the  contracts  ; 

3.  The  best  way  to  accelerate  LOA's  process  and 
provide  the  required  information  in  the  shortest 
time  possible; 

4.  The  design  of  a  prototype  decision  support 

database  system  using  PC/FOCUS  DBMS  on  an  IBM  XT  or 
AT  computer  to  replace  the  current  manual  POW 
system. 

The  development  of  such  a  system  creates  a  valuable  DSS 
tool,  the  database,  to  support  the  POW.  This  system  may  be 
considered  as  a  DSS  generator  for  developing  a  specific  DSS 
to  include  all  functions  of  POW  after  getting  feedback  from 
users  . 


B.  BACKGROUND 

The  strategic  policy  of  the  Egyptian  Government  since 
1973  has  been  to  procure  weapons  systems  and  military  equip¬ 


ment  from  different  countries  in  order  to  modernize  the 


Egyptian  Armed  Forces.  The  Egyptian  Armament  Authority  (  A  A  ; 
is  responsible  for  the  procurement  activities  from  foreign 
countries.  To  effectively  accomplish  its  job,  it  has  front 
offices  in  those  countries,  called  Procurement  Offices  (PO). 
The  Procurement  Office  in  Washington  (POW)  is  one  of  these 
offices.  The  POW  deals  with  two  kinds  of  procurements , 
■commercial  procurement  of  the  military  items  from  the  open 
market  inside  the  USA,  and  government  procurement  from  the 
Government  of  the  USA.  The  POW  functions  are  summarized 
below. 

The  following  are  the  POW  functions  outlines. 

1 .  Commercial  Procurement 

The  POW  does  the  following  important  functios:  1  ) 
receives  Requests  For  Proposals  (RFP’s)  coming  from  AA,  (2) 
prepares  vendor  list  of  the  eligible  and  suitable  vendors  to 
receive  the  RFP's,  (3)  calls  vendors  for  bids,  (4)  receives 
and  verifies  proposals  from  vendors  and  forwards  then  to  A A 
(5)  Monitors  and  administers  the  active  contracts  inside  the 
USA  , 

2 ;  Government  Procurement 

All  the  requests  for  purchasing  weapons  from  the  USA 
Government  must  be  submitted  on  a  special  form  called 
Request  of  Offer  and  Acceptance;  (ROA).  After  many  procedur¬ 
es  in  the  USA  administration  the  accepted  ROA  becomes  a 
•Letter  of  Offer  and  Acceptance  (LOA)  which  is  a  contract 
between  the  United  States  of  America  and  Egypt.  The  LOA's 


are  prepared  in  Egypt  by  the  A  A  and  the  specialized  depart¬ 
ments  according  to  our  needs  and  the  weapons  acquisition 
plan.  The  PQW  responsibilities  in  this  kind  of  procurement 
are:  (1)  receive  all  the  ROA's  coming  from  AA  and  forwards 
them  to  the  USA  Security  and  Assistance  Center  (USASAC), 
"which  is  responsible  for  Foreign  Military  Sales  to  alien 
and  friendly  countries",  (2)  keep  track  of  all  ROA's  status 
sent  to  USA.SAC  until  final  acceptance  as  an  LOA,  and  (3) 
receive  and  process  requisitions  for  Purchasing  spare  parts 
needed  for  the  weapons  already  purchased  from  the  USA  and  in 
the  service  of  Egyptian  Armed  Forces. 

C.  PROBLEMS  TO  BE  SOLVED 

Due  to  the  continued  growth  of  the  numbers  of  RFP's, 
open  contracts,  and  LOA's,  the  current  manual  system  needed 
to  be  improved  to  allow  better  performance  of  the  procure¬ 
ment  process.  The  following  are  the  major  problems  with  the 
current  P 0 W  system. 

1 .  RFP's  Function 

This  process  requires  a  great  deal  of  effort  to 
effectively  decide  who  are  the  suitable  vendors  to  receive  a 
particular  RFP.  A  pre-selected  criterion  must  be  applied  for 
each  vendor.  The  growing  numbers  of  RFP's  coming  from 
Egypt ,  the  large  numbers  of  vendors  available  in  USA, 
and  binding  time  constraints  are  all  important  factors  that 
may  be  causing  a  delay  in  this  process. 


2 .  Monitor  Open  Contracts 

A  large  number  of  contracts  must  be  monitored  for 
payment,  shipment,  and  training  of  personnel.  Invoices  need 
to  be  verified  and  payed  to  prevent  problems  of  missed  or 
double  payments  of  some  invoices.  Different  kinds  of  payment 

I 

“  and  fund  sources  must  be  monitored  too.  The  present  manual 

system  requires  significant  effort  to  effectively  deal  with 
these  ac t i v  i t i e s  .  ( Abo u t  100  man  hours  per  working  day  are 
needed  to  do  these  activities). 


3 .  LOA's  Functions 


The 

USA  Foreign 

Military 

Sales 

(FMS)  procedures 

are 

very  conservative  and 

lengthy. 

The 

POW  acts  as 

a 

co- 

ordinator 

between  the 

AA  and 

the 

USASAC.  The 

POW 

i  s 

responsible 

for  keeping 

track 

of  the  status  of 

each 

LOA 

submitted  to  USASAC.  This  process  takes  a  long  time  to  be 
completed  (at  least  two  months).  Speeding  up  this  process 
requires  a  good  monitoring  system  to  keep  track  of  the  LOA's 
and  provide  information  to  both  sides  in  the  shortest  time 
possible. 

D.  SCOPE,  LIMITATIONS,  AND  METHODOLOGY 

This  thesis  concentrates  on  the  first  two  phases  of  the 
DSS  development  life-cycle  ,  ie.  systems  analysis  followed 
by  the  design  of  a  prototype  database  for  the  commercial 
procurement  activities  of  P 0 W .  The  software  utilities  of 


PC/FOCUS  DBMS  will  be  used  to  develop  the  prototype.  The 


B 


POW  ORGANIZATION 


POW  consists  of  the  POW  Director,  POW  Director  Assistant 
Officers  or  the  Specialized  Officers  (SO's),  Contracting 
Officer  (CO),  Financial  Officer  (FO),  Shipment  Officer 
(SHO),  and  Admi n i s t r a t i ve  Officers  (AO), (These  abbreviations 
will  be  used  in  the  DFD  and  data  dictionary.).  All  officers 
are  selected  from  different  Forces  of  Egyptian  Armed  Forces 
(EGAF)  to  represent  the  major  specializations  in  EGAF. 

1 .  Organization  Chart 

Figure  2.1  shows  the  organization  of  POW.  As  we  can 
see,  the  POW  Director  has  the  overall  responsibility  for  the 
procurement  functions  inside  the  USA.  The  other  officers 
assist  him  in  doing  his  job.  The  organization  consists  of 
sections.  Five  specialized  sections  represent  the  major 
topic  areas  of  Egyptian  Armed  Forces,  each  one  is  headed  by 
a  specialized  officer  in  the  particular  area.  The  Administr¬ 
ation  and  Control  section  headed  by  a  qualified  officer  in 
administration.  The  Financial  and  Accounting  section  headed 
by  an  officer  from  the  Financial  Affairs  Authority.  The 
Shipment  section  headed  by  a  qualified  officer  which  is 
responsible  for  monitoring  shipment  of  contract  items  to 
Egypt  . 

2 .  The  POW  Procurement  Responsibilities  in  USA: 

a.  Apply  and  follow  the  Egyptian  defence  procurement 
laws  and  regulations. 


Use  funds  available  in  the  most  effective  and 
flexible  way. 

Assure  appropriate  contract  type. 

Reduce  the  procurement  cost  and  shorten  the 
procurement  period. 


f.  Improve  vendor  selection  function  and  keep  an 

up-todate  information  about  vendors. 

g.  Increase  competition  between  vendors. 

h.  Develop  and  use  standard  operation  and  support 
systems  to  perform  the  procurement  function 
effectively. 

i.  Monitor  shipment  of  the  contract  items  to  the 

country. 

j.  Monitor  training  of  personnel  associated  with  the 

contracts. 

The  POW  director  is  responsible  for  proper  execution 
of  all  the  above  functions.  Figure  2.2  shows  all  AA  requests 
from  POW  and  Figure  2.3  shows  POW  relationships  with 

external  agencies. 

3 .  Job  Responsibili t y _ of  the  Specialized  OfficersCS 0 ) : 


Apply  all  the  procurement  functions  as  stated  in 
Item  2 . 

Follow  the  orders  and  directives  of  the’  POW 
Director. 


Check  the  RFP's  received  from  AA  for  proper 
specifications  and  style  before  forwarding  to 
vendors  . 

Apply  vendor  selection  rules  and  criteria  to 

achieve  full  and  open  competition  between  vendors. 

Maintain  fairness  and  equal  opportunity  among  all 
vendors  by  providing  them  with  all  information 
concerning  a  particular  RFP. 

Receive  and  verify  proposals  for  completeness 

before  sending  them  back  to  AA . 

1  9 


“JiV  M**  "J*  ** 


g.  Check  all  received  payment  documents  from  vendors 
and  approve  them  for  payment. 

4 .  Job  Responsibilities  of  the  Contracting  Officer : 

a.  Apply  Egyptian  defence  legislation  and  directives 
related  to  the  procurement  process. 

b.  Check  all  contract  terms  for  correctness  and 
completeness  before  signing  by  PQW  Director. 

c.  Check  and  review  vendor  financial  status  be  f  ore 

putting  them  in  the  vendor  list. 

d.  Keep  track  of  all  open  contracts  and  monitor 
vendor  performance  in  contract  implementation. 

e.  Prepare  a  termination  notice,  if  necessary,  for 
inactive  vendors. 

f . .  Deal  with  all  problems  and  complaints  from 

vendors. 

g.  Participate  in  the  procurement  committees  in  PQW 

and  check  that  all  vendors  are  qualified  to  attend  a 
committee  and  have  all  the  necessary  certificates 
and  warranty  letters. 

The  following  sections  describe  the  POW  system 

functions.  Two  types  of  procurements  are  exist,  the 
commercial  procurement  and  the  government  procurement. 


C.  COMMERCIAL  PROCUREMENT  FUNCTION 

The  commercial  procurement  function  is  divided  into  five 
processes,  as  shown  in  the  DFD  in  Figure  2.4. 

1.  RFP's  Function 

2.  RFC's  Function 

3.  Fund  contracts. 

4.  Administer  contracts 
5  . 
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tacn  one  of  the  above  processes  is  expandea  into 
several  other  processes  in  a  top  down  fashion  to  snow  more 
details.  In  each  level  of  details,  a  walkthrough  is  present¬ 
ed  to  explain  each  process  associated  with  the  DFD.  In  the 
data  dictionary,  a  detailed  description  of  the  processes  is 


1  .  RFP ' s  Function 


The  RFP  is  the  official  communication  from  the 
Government  of  Egypt  to  the  market.  For  easy  explanation,  we 
take  a  particular  RFP  and  follow  its  sequence.  Figure  2.5 
illustrates  this  process  as  a  DFD.  The  process  starts  when 
a  particular  Force  or  Department  of  EGAF's  "requester"  asi<3 
the  Ministry  of  Defense  (MoD)  for  funding  for  certain  kinds 
of  military  items  from  the  USA.  After  receiving  a  fund 
letter  from  MoD,  a  Committee  is  designated  to  prepare  the 
RFP.  The  objective  of  tne  RFP  is  to  provide  prospective 
vendors  with  adequate  information  and  guidance,  presentee  in 
a  clear  and  logical  manner.  Basically,  preparation  of  tne 
RFP  is  a  team  effort. 

a.  Receive  RFP  by  AA 

After  final  approval  of  the  RFP,  the  requester 
sends  it  to  AA.  Any  particular  RFP  usually  contains  the 
following  information: 

(  1  )  Terms 

(2J  Evaluation  factors 
(  d  )  Specification 
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(4)  Delivery  schedule 

(5)  Quality  assurance 


b. 

Check 

RFP 

in  AA 

The 

RFP 

i  s 

checked 

against 

the  annual 

procurement 

plan 

of 

the 

requester . 

The  RFP 

must  be  clear  , 

complete,  and  consistent  with  the  requirement  of  procurement 
so  that  it  provides  all  vendors  with  the  same  understanding. 
After  checking,  the  AA  sends  the  RFP  to  PQW. 

c.  Check  RFP  in  POW 

Once  received  by  the  POW,  the  RFP  is  registered 
in  the  General  Log  Book  by  the  Adm i n s t e r a t i v e  section,  and 
then  routed  to  the  Specialized  Officer  in  the  area,  who 
reviews  the  RFP  to  be  sure  that  the  specifications  are  clear 
and  complete  and  items  are  clearly  identified.  (Figure  2.6) 

d.  Select  Vendors 

The  SO  selects  vendors  who  will  receive  the  RFP 


from  the 

vendor 

lists 

available 

in  POW, 

or  by  using  a 

special 

catalog 

called 

the  Thomas  Register 

which  contains 

most  of 

vendors 

in  the 

USA.  He 

prepares 

a  list  of  the 

vendors 

matched 

with 

the  RFP 

item  specifications  and 

approves 

it  with 

the  POW  Director. 

e 

.  Issue 

RFP 

The 

necessar  y 

number 

of  copies 

of  the  RFP  is 

prepared  and  mailed  to  the  selected  vendors.  First  time 
vendors  must  fillout  a  special  Qualification  Form.  The 
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letter  sent  to  the  vendors  clarifies  all  the  general  terms 
and  conditions  that  must  be  followed  by  the  vendors  as  well 
as  the  closing  date  for  receiving  the  proposals.  Sometimes, 
for  important  RFP's,  a  pre-proposal  conference  may  be 
scheduled  to  allow  vendors  to  clarify  sections  of  the  RFP 
they  may  not  fully  understand. 

f.  Check  Incomming  Proposals 

SO  checks  and  reviews  all  incoming  proposals. 
Only  relevant  and  complete  proposals  from  qualified  vendors 
are  sent  to  Egypt.  (Figure  2.7) 

2 .  RFC's  Function 

Sometimes,  AA  authorizes  POW  to  contract  with  vend¬ 
ors.  It  sends  a  Request  For  Contracting  (RFC)  to  POW.  The 
RFC  must  contains  all  the  necessary  documents  for  doing  the 
contract  process.  Two  kinds  of  requests  may  be  received,  RFC 
with  a  specific  vendor  already  selected  by  AA  or  a  list  of 
technically  accepted  vendors  to  choose  from.  The  awards  are 
generally  based  on  cost.  If  two  vendors  have  similar  cost 
bids,  previous  contracts  with  Egypt  or  the  USA  Armed  Forces 
are  considered.  The  following  are  the  procedures  for  a 
particular  RFC:  (Figure  2.8) 

a.  The  Specialized  Officer  (SO) 

Receive  and  review  the  RFC  in  the  area.  The  most 
important  document  received  with  the  RFC  is  the  technical 
evaluation  and  acceptance  of  vendors  and  the  best  and  final 
offers  of  each  vendor. 
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b.  The  Financial  Officer  (FO) 

Checks  availability  of  funds  for  RFC. 

c.  The  Administrative  Officer  (AO) 

Prepares  the  Contracting  Implementation  Plan 
(CIP)  and  the  meeting  schedule  with  vendor(s).  The  AO 
informs  vendors  of  the  date  and  time  of  the  negotiation 
meeting.  The  negotiation  period  should  not  exceed  two 
weeks. 

d.  Vendors  Negotiation 

The  PQW  Director  designates  a  team  .  for 
discussions  and  negotiation  with  vendors.  The  team  consists 
of  members  from  specialized  officers,  the  contracting 
officer,  and  the  financial  officer.  The  negotiation  issues 
are  str aight forward  and  consist  generally  of  insuring 
competition  between  vendors  and  obtaining  the  best  price  and 
conditions  possible. 

e.  Pre-Award  Survey 

This  servey  must  be  undertaken  by  the  team.  The 
factors  to  be  considered  for  each  vendor  are: 

(1)  adequate  financing, 

(2)  ability  to  meet  delivery  and  specifications, 

(j)  satisfactory  record  of  performance, 

(4)  satisfactory  record  of  integrity, 

(5)  necessary  organization,  and 

(6)  necessary  facilities  and  equipment. 
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f.  Team  member  responsibilities  in  RFC  Process 

( 1 )  Contracting _ Officer  .  Prepares  the  contract 

draft  paying  special  attention  to  the  contract  terms  and 
conditions. 

( 2 )  Financial  Officer  .  Calculates  tne  amojnt  o 
dollars  needed  to  fund  the  contract  and  tne  initial 
deposits.  He  also  prepare  the  payment. 

( 3 )  Specialized  Officer  .  Checks  all  thetechnical 
terms  of  the  contract  e.g.  item  catalog  numbers,  warranty 
period, inspection  plan, technical  assistance, training  plan. 

(4)  Administrative  Officer.  Collects  and  Keeps  all 
documents  of  the  RFC  and  records  all  events  in  a  special  Log 
Book. 


(5) 

POW 

Director.  Checks 
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final 
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then  invite 

the 

selected 

vendor 

to  sign  the 

contract  in  POW. 

All 

the 

contract  related 

documents  are 
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a  file  until  the  implementation  phase.  A  contract  monitor 
record  is  created  to  keep  all  active  information  about  tne 


contract . 
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3 .  Fund  the  Contracts 

Two  types  of  fund  source  are  available:  budget  ana 
loans.  Figure  <£.11  shows  the  main  process  of  funding 

contracts.  Processing  of  any  procurement  activities  cannot 
be  started  unless  PQW  receives  the  financial  letter  that 
assigns  the  money  value  and  the  source  of  funds  to  be  used. 
The  preparation  of  defense  budget  and  loans  is  beyond  the 
scope  of  P  0  W  functions.  The  POW  responsibility  is  to 

effectively  manage  funds  dedicated  to  new  or  currently 
active  contracts.  The  cash  needed  over  a  period  of  time  must 
be  carefully  calculated.  Monitoring  the  cash  flow  and  banK 
status  is  one  of  PGW's  major  functions.  The  following  are 
the  procedure  to  fund  the  contracts, 
a.  Funding  from  Budget 

( 1 )  The  Needed  Documents  are  (Figure  2.12): 
FUNDING  LETTER  — Received  from  AA. 

LETTER  OF  CREDIT  —  Received  from  the  Central 
National  3a  nk  of  Egypt  (CN3GEG)  amounting  to  the 
total  value  of  contract  and  the  advance  deposit 
to  be  paid  to  the  vendor. 

LETTER  OF  G U A R A N TE E -- R e c e i v ed  from  vendor  for 
the  security  of  contract  execution  from  vendor. 

LETTER  OF  GUARANTEE  —  Received  from  vendor  for 
the  amount  of  advance  deposit  he  receives  after 
signing  the  contract. 

OTHER  DOCUMENTS  AND  CERTIFICATES — These  documents 
are  related  to  the  contract  e.g.  warranty,  inspec¬ 
tion,  source  manufacture  certificate  etc. 

( 2 )  Open  Letter  of  Credit .  Send  letter  to  tne 


specified  bank  to  open 


in  favor  of  the  vendor  a  confirmed 


and  irrecoverable  letter  o:'  :  r  e  a  1 :  ,  in  a  prepared  I'orr 

letter. 

(3)  Activate  the  Contract.  The  contract  is 
activated  and  implemented  upon  the  agreement  date, 
b.  Funding  from  Loans 

(1)  Determine  the  Source  of  Fund.  The  initial 
funding  letter  w  i  t  n  tne  RFP  determines  the  source  of  funds 
and  whet  n  e  r  or  not  it's  funded  from  USA  loans.  POW  considers 
that  when  preparing  the  vendor  list  for  the  RFP. 

(2)  Use  the _ Loans  .  The  loans  are  already 

approved  and  available  for  withdrawal.  One  loan  may  serve 
many  contracts.  Loan-based  procurements  are  constrained  by 
many  factors  such  as:  vendor  selection,  manufacture  product, 
and  limited  amount  of  dollars.  AA  understands  these 
constraints  and  follows  its  rules  accordingly. 

( 3 )  Process  Funding  from  Loans .  After  finish¬ 

ing  the  contracting  pnase,  POW  sends  a  letter  to  the  Defense 
Security  and  Assistance  Agency  (DSAA)  asking  them  for 
funding  the  contract  from  a  loan,  (Figure  2.13  )  shows  the 

procedures  of  loan  funding.  Two  documents  must  be  supplied 
with  this  letter:  a  copy  from  the  signed  contract  and  tne 

Justification  Sheet  which  is  prepared  by  DSAA  to 

assist  the  procurement.  The  request  is  processed  oy  DSAA 
and,  if  accepted,  a  letter  is  sent  with  the  Case  Designator 
number  for  the  contract,  which  serves  like  tne  credit  letter 


from  NBQEG 


in  the  budget  base  procurement.  POW  informs  the 


vendor  by  that  number  to  start  the  implementation  phase  of 
the  contract. 

4 .  Administer  Open  Contracts 

Each  specialized  officer  is  responsible  for 
monitoring  a  group  of  contracts  in  his  area.  The  contracts 
are  divided  into  groups  according  to  specialized  areas.  The 
major  functions  of  contract  administrations  are  shown  in 
Figure  2.14.  The  following  are  the  description  of  each 
function. 

a.  Payment 

Much  effort  and  time  are  needed  to  do  this 


function.  The  following  are  the  payment  procedures  as 
presented  in  Figure  2.15- 
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Figure  2  1  3  Fund  From  Loan 
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Figure  2. 1  A  Administer  Open  Contracts 
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Figure  2.  15  Payment 


compares  the  invoice  with  the  shipment  notice  from  FF  to  see 
that  they  match.  He  checks  the  previous  payment  documents  to 


make  sure  there  is  no  duplication.  He  then  approves  tne 
payment  from  the  technical  point  of  view  and  routes  tne 
payment  documents  to  the  Financial  Officer  (FO). 

(4)  Check  the  Documents  by  FO.  The  FO  cnec<s 
t^he  invoice  amount,  the  source  of  funds,  the  previous 
payments,  and  the  approval  of  the  SO.  He  prepares  the  check 
or  the  money  order  and  approves  the  payment  from  the  PoW 
Director . 

b.  Monitor  Personnel  Training 

Figure  2.16  shows  the  training  procedures.  Tne 
training  may  be  done  in  Egypt  or  in  vendor  training  center 
in  USA.  In  the  first  case,  the  vendor  must  inform  the  POw  at 
least  two  months  before  the  training  date  of  the  names  of 
expertise  who  will  train  our  personnel.  A  special  enquiry 
form  is  sent  to  the  vendor  to  supply  this  expertise 
information.  The  second  case,  when  training  must  be  done  in 
USA,  vendor  must  inform  POW  six  month  before  the  training 
date  of  the  date,  duration,  and  locations  of  the  training 
center,  and  the  number  of  personnel  who  will  train. 

c.  Monitor  Shipment  of  Items  to  the  Country 

A  Freight  Forwarder  ( FF )  company  is  contracted 
to  do  the  shipment  of  all  items  related  to  contracts.  This 
company  is  responsible  for  safe  and  timely  transportation  of 
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Figure  2.  16  Mointor  Personnel  Training 


contracts  items  to  Egypt.  It  keeps  all  the  documents  and 
information  related  to  the  contents  of  packages  delivered 
from  all  vendors  to  the  front  door  of  the  F F  company.  Figure 
2.17  shows  the  shipment  main  functions.  The  shipment  officer 
sets  the  priority  of  shipment  to  the  country  according  to  AA 
demands  and  informs  FF  to  take  the  necessary  actions.  The 
normal  shipment  is  done  by  the  FF.  The  shipment  officer 
receives  a  weekly  progress  report  from  FF.  This  report 
contains  the  quantity  shipped  during  the  week  and  the 
inventory  level  inside  the  FF  store  and  any  problems  to  be 
solved.  FF  receives  the  delivered  items  from  the  vendor  and 
signs  a  receipt  to  the  vendor.  This  receipt  must  be  included 
with  the  payment  document  when  delivered  to  POW. 

POW  is  equipped  by  a  computer  terminal  connected 
to  the  FF  computer  center  to  access  the  information  about 
the  shipping  status  and  the  inventory  level, 
d.  Reporting 

In  general,  the  POW  is  the  information  link 
between  AA  and  USA  government  and  market.  Good  communication 
between  POW  and  AA  is  essential  to  properly  accomplish  the 
procurement  function.  Reports  can  be  classified  under  the 
following  kinds  of  categories  (Figure  2.18):  status 

reports,  analysis  reports,  progress  reports  ,  comparison 
reports,  evaluation  reports  ,  technical  reports,  market 
research  report,  etc.  In  the  next  chapter  we  present  details 
of  all  reports  used  and  needed  by  POW. 
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The  procurement  function  in  the  USA  must  be  based  on 

competition  between  vendors.  The  Manual  of  Acquisition 

Topics  in  the  Navy  Acquisitions  [Ref.  5],  states: 

Competition  received  widespread  attention  during  1984. 
President  Reagan  stated  that  competition  "is  the  single 
most  important  source  of  innovation,  efficiency  and 
growth  in  our  economy. 

Rear  Admiral  Giordano,  SC,USN,  Chief  of  the  Supply 

Corps,  further  stated  that:  [Ref.  5] 

Competition  makes-  good  business  sense,  and  I  want  co 
make  it  clear  that  increasing  competition  must  be  a 
primary  objective  of  all  personnel  involved  in  logistics 
management. 

Commodore  Stuart  F.  Platt,  SC,  USN ,  as  the  first 

Competition  Advocate  General  (CAG)  of  the  Navy.  He  stated: 

Competitive  procurement  represents  the  extension  of  the 
principle  of  fairness  into  the  defense  acquisition 
process.  The  public  trust  placed  in  those  who  obligate 
public  funds  includes  the  assurance  that  a  fair 
opportunity  will  be  provided  to  all  who  can  meet  the 
government's  needs.  One  effect  i.ve  way  to  significantly 
reduce  costs,  and  thereby  be  able  to  afford  our  defense 
requirements,  is  to  increase  the  use  of  competition. 

The  navy  is  now  emphasizing  competitive  procurement 
strongly. 

PQW  should  apply  the  competitive  procurement  as  well 
Figure  2.19  shows  the  Vendor  List  source  schema  and  Figure 
2.20  shows  the  main  processes  of  generating  the  Vendor  List. 
Building  and  maintain  a  good  database  about  vendors  is 
essential.  We  call  it  the  vendor  list  in  the  manual  system. 
Bad  selection  of  vendors  may  seriously  affect  our  Armed 
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Forces.  A  number  of  different  factors  can  be  measured  to 

provide  a  basis  for  evaluating  vendors.  However,  depending 
on  the  type  of  military  items  to  be  purchased  and  the  past 
experience,  factors  may  vary  in  their  degree  of  importance. 

Any  new  vendor  to  POW  must  pass  through  extensive 
investigation  to  be  sure  that  they  have  the  qualifications 
to  be  included  in  our  vendor  list.  Figure  2.21  shows  the 
procedures  of  evaluating  new  vendors.  The  following  factors 
are  taken  into  consideration  when  evaluating  vendors: 

( F igure  2.21) 

Business  Assets  Value  (BAV) 

-  Business  Start  Date  (BSD) 

Source  Manufacturer,  Distributor,  or  Broker 
Quality 

Supplier  to  USA  Ar m y / N a v y / A i r  Force 

Level  of  Satisfaction  of  Previous  Contracts 

Business  Activity  (BA) 

After  recording  the  above  information  in  a 
Qualification  Form,  POW  validates  this  information  by 

asking  a  market  research  and  consumer  association  to  assess 
the  financial  capability  of  the  vendor.  This  validation  is 
always  done  for  a  new  vendor  or  in  Pre-Award  Surveys.  The 
following  are  some  quantitative  and  qualitative  Figures  that 
should  be  considered  to  review  vendor  status. 
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Figure  2.2  1  Verify  Vendors 


a.  Quantitative  Items 
Trends  in  : 

-  Gross  margin  ratio 

-  Sales 
Debt/equity  ratio 

-  Return  on  investment 
Cash  flow/debt 
Working  capital  needs 
Current  ratio 

-  account  r e c e i v a b 1 e / pa y a b 1 e  turnover 

-  Inventory  turnover 

b.  Qualitative  Items: 

-  Credit  ratings 

-  Notes  to  financial  statements 
Market  share 

Capital  asset  stability 

The  type  of  evaluation  required  to  determine  vendor 
capability  varies  with  the  nature,  complexity,  and  dollar 
value  of  the  purchase  to  be  made. 

POW  is  responsible  for  processing  only  the  proposals  of 
qualified  vendors.  The  first  filter  to  catch  the  non¬ 
qualified  vendors  is  during  the  RFP  process.  The  second 
filter  is  during  checking  and  verification  of  new  vendors, 
and  the  third  filter  is  during  the  Pre-Award  Survey. 


D.  GOVERNMENT  PROCUREMENT 

1 .  Foreign  Military  Sales  (FMS) 

a.  Background 

The  United  States  has  been  assisting  friendly 
countries  in  establishing  adequate  defensive  forces  for 
their  national  security  and  for  resisting  external 
aggression.  This  policy  is  essential  to  the  security  of  the 
USA  itself. 

b.  FMS  Important  Issues: 

(1)  No  commercial  export  license  may  be  issued  for  the 
sale  of  major  defense  equipment  valued  at  $25 
million  or  more,  except  through  an  FMS  case. 

( 2 )  The  President  of  the  USA,  30  days  prior  to  giving 

his  consent  for  sales,  must  submit  to  the  Speaker  of 
the  House  of  Representatives  and  Committee  on 
Foreign  Relations  of  the  Senate  ,  a  written 

certification  of  the  proposed  arms  sale.  The 

Congress  may  veto  this  proposed  transfer.  Further¬ 
more,  the  certification  submitted  to  the  Congress 
shall  be  unclassified  (classified  information 
submitted  separately)  to  permit  public  disclosure. 

(3)  The  cost  and  interest  to  be  charged  to  the  foreign 
country  will  include  administrative  services,  plant 
and  production  equipment  cost,  and  a  pr opo r t i o n a t e 
amount  of  any  nonrecurring  cost  of  R  &  D. 

(4)  Commercial  sales,  through  export  licenses, of  major 
defense  systems  are  limited  of  the  value  of  $25 
millions.  tRef.  6] 

c.  FMS  Authority  Distribution 

Figure  2.22  shows  the  inter-relations  between 
the  USA  authority  in  FMS.  The  following  are  the  role  of  the 


main  USA  authoroties  envolved  in  tnis  system. 


(1)  Congress .  Their  are  various  laws  for  the 
purpose  of  guiding  and  controlling  the  FMS  process.  One  of 
the  key  laws  is  that  the  President  of  the  United  States  must 
submit  to  the  Congress,  30  days  prior  to  his  consent,  every 
proposed  sale  that  exceeds  $25  million.  Moreover,  the 
Congress  requires  annual  reports  from  the  President  on  the 
status  of  FMS  [Ref.  14]. 

(2)  State  Department.  The  State  Department  is 
primarily  concerned  with  U.S.  security  policy  all  over  the 
world,  and  so  established  the  Bureau  of  Politics  -  Military 
Assistance  [Ref.  7J.  This  Bureau  generates  policy  guidance 
and  procedures  concerning  the  issues  of  USA  security,  FMS 
and  arms  control.  Within  the  bureau  their  are  three  offices 
that  maintain  constant  contact  with  the  DoD  and  other 
departments  as  necessary  for  the  approval  of  military 
exports.  The  three  offices  are: 

Office  of  Security  Assistance  and  Sales  (SAS) 

-  Office  of  Munitions  Control  (OMC) 

Office  of  Planning  and  Analysis  for  International 

Security. 

(3)  Department  Of  Commerce.  The  Department  of 
Commerce  is  primarily  responsible  for  the  overall  economic 
growth  and  technical  development  of  the  USA.  Within  the 
department,  the  office  that  maintains  inter-depart  mental 
discussions  affecting  the  international  trade  is  the  office 
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Figure  2.22  Inter-relations  Between  the  USA  Authoroties 
in  Foreign  Military  Sales  System 


of  Domestic  and  Business  Administration  (DIBA).This  office 

is  concerned  especially  with:  [Ref.  14] 

Competitive  assessment  of  US  industry  in  domestic 
and  world  markets. 

Expansion  of  export  and  export  control 
administration  . 

Federal  recognition  and  participation  in  inter¬ 
national  exposition  and  trade  fairs. 

( 4 )  Department  of  Treasury .  The  Department  of 
Treasury,  in  the  area  of  foreign  trade,  participates  in  the 
financial  negotiations  between  the  US  and  foreign  countries. 
It  exercises  broad  control  over  military  and  commercial 
export  programs,  assuring  that  they  are  compatible  witn 
the  US  trade  and  security  policy.  It  also  reviews  trade 
agreements  for  credit  risk  evaluation,  assuring  the  best 
utilization  of  US  Government  backing  to  credit  institutions 
[Ref.  21]. 

(5)  Department  of  Defense  (DoD).  The  DoD  is 

the  principal  actor  involved  in  FMS.  The  DoD  serves  as  tne 
main  co-ordinator  for  all  the  objectives  of  the  other 
departments  concerning  FMS.  There  are  four  major  offices 
involved  in  military  assistance  and/or  the  sale  of  military 
items:  [Ref.  14] 

Defense  Security  Assistance  Agency  (DSAA)  DS  A  A 

Serves  within  the  DoD  as  the  responsible  office  for 
Government  to  Government  FMS,  performed  under  the  control  of 
tne  Secretary  of  Defense.  It  was  established  in  1971  and  has 


been 


responsible 


since 


then 


for  the  generation,  and 


maintenance  of  procedural  guidance  according  to  the 

Military  Assistance  and  Sales  Manual,  DoD  Manual  5  10  5. j  a  - M 
[Ref.  7j.  In  addition  to  participation  in  top  level 
planning,  programming,  and  reviewing  of  FMS.  DSAA  performs 
the  following  functions:  [Ref.  7] 

*  Conducting  negotiations  with  the  customers. 

*  Interfacing  with  and  assisting  US  industry,  in 
its  effort  to  receive  export  licenses  from  the 
State  Department  for  doing  business  with  foreign 
countries  . 

*  Managing  FMS  credit  arrangement  and  guarantees 
of  private  financing  of  FMS. 

-  Office  of  Assistance  Secretary  of  Defense  for 
International  Security  Affairs  (OASD/ISA).  The  OASD  (ISA) 
develops  policies  concerning  international  security  through 
a  mutual  agreement  with  the  State  Department.  Within  ISA  the 
Deputy  Assistance  Secretaries  (Regional  desks),  provide  and 
prepare  for  their  regions  a  threat  analysis  for  a  specific 
country  based  upon  its  potential  enemies  and  the  military 
capaoilities  of  both  sides.  The  Director  of  Strategic  Trade 
and  Disclosure  within  ISA  provides  official  DoD  positions 
on  any  proposed  military  or  commercial  exports  that  has 
possible  military  application.  This  is  accomplished  in 
coordination  with  Department  of  Commerce  and  the  State 
Department.  The  review  of  any  export  license  is  done  by  the 
Inter-agency  Board  consisting  of  representatives  from  the 
Department  of  State,  Department  of  Commerce,  Department  of 


Treasury  and  the  Director  of  Strategic  Trade  and  Disclosure. 


-  Elements  of  the  Armed  Forces  and  JGS.  The  State 
Department's  Office  of  Munitions  Control  (OMC),  submits  the 
export  application  of  the  foreign  country  to  the  concerned 
service  Army  (Director  of  International  Logistic),  Navy 
(Security  Assistance  and  Sales).  Each  service  has  major 
functions  to  achieve  related  to  FMS:  [Ref.  14] 

*  Upon  receipt  of  the  export  application,  through 
the  DoD  Director  of  Strategic  Trade  and 
Disclosure,  it  formalizes  and  presents  its 
position. 

*  It  provides  the  detailed  analysis  and  evalua¬ 
tions  that  are  necessary  for  the  negotiation 
proc  ss  . 

*  It  assists  DSAA  in  the  process  of  the 

negotiations. 

*  It  manages  and  administrates  the  sales  activity 
during  its  performance. 

2 .  Egyptian  Government  Procurement  from  USA 

The  major  two  kinds  of  military  procurement  from  tne 
USA  are  the  Government  procurement  of  Major  Defense  Items 
and  the  Spare  Parts  Procurement  for  Weapons  already  in 
service  and  purchased  from  the  USA.  Both  kinds  of  procure¬ 
ment  must  be  processed  according  to  the  USA  FMS  rules  and 
regulations.  Major  defence  items  procurement  such  as 
aircraft,  tanks,  and  air  defense  weapons  is  lengthy 
procedure.  POW  must  be  alert  and  responsive  to  speed  up  this 
process  during  its  performance. 

The  POW  acts  as  a  co-ordinator  between  AA  and  the 


USA 


Security 


Assistance 


Center 


(SAC),  which  is  the 


responsible  organization  i  n  s i o  e  one  -in  Government  for 
administrating  the  requests  of  friend*/  foreign  countries  to 
purchase  major  defence  items  ana  military  equipment.  The  F  M  S 
policy  procedures  must  be  well  understood  to  speed  up  this 
kind  of  procurement.  A  network  of  interrelation 

responsibilities  starting  from  the  President  of  USA, 
Congress,  Department  of  State,  Department  'of  Treasury, 
Department  of  Commerce,  and  Department  of  Defense  are  ail 
involved  in  processing  the  requests  of  major  defence  items 
purchases.  Many  factors  must  be  considered  in  doing  this 
kind  of  procurement.  The  political  issues  also  have  a  great 
effect  on  this  kind  of  procurement. 

The  following  details  the  steps  in  the  two  kinds  of 
Government  procurement.  (Figure  2.2J) 

a.  Major  Weapons  Systems  Procurement  Steps 

The  basic  document  in  this  kind  of  procurement 
is  the  Letter  of  Offer  and  Acceptance  (LOA)  (DD  FORM  1513). 
The  LOA  is  also  known  as  a  "Request  Of  Sale"  or  "Request 
For  Price  and  Availability".  After  the  acceptance  of  the 
LOA  by  the  USA  Government,  it  becomes  a  contract  between  the 
two  countries.  The  Government  procurement  consists  of  eight 
steps  initiated  by  submitting  the  Request  for  Letter  of 
Offer  (RLO).  All  USA  Forces  have  similar  procedures  for  the 
FMG.  The  following  procedures  are  based  on  the  Air  Force  FMS 
J  .  3 .  Department  of  the  Air  Force,  "  logistics  -  Foreign 


Military  Sales"  AFM  40U-j,  17  Feb  197b), 


L  R  e  f  .  o  J  . 
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The  RLO  must  be  prepared  and  reviewed  very 
carefully  by  the  Top  Level  in  Egyptian  Minister  of  Defense 
(MoD),  AA,  and  the  Major  Armed  Forces.  A  special  Forms  of 
RLO  must  be  prepared  known  as  a  "  Checklist  for  weapons 
system  sale  request. 

The  following  are  example  of  the  USA  Air  Force  Checklist 

Main  subjects: 

*  Country 

*  Aircraft  Mod e 1 / De s i g n a t o r / Se r i e s /  (MDS) 

*  Quantity 

*  Basic  Configuration 

*  Source  Data 

*  Delivery  Data 

*  Missiles/ECM  P od s / Bomb s / Ammo 

*  Anticipated  LQA  Acceptance 

*  Operational  Concepts 

*  Maintenance  Concepts 

*  Supply  Concepts 

*  Contractor  Engineering  and  Technical  Services  (GETS) 

*  Weapons  Systems  Logistics  Officers  ( WSLO )/ System 

*  Acquisition  Officer  (SAO) 

*  Training  Concept 

*  Insurance 

*  Quality  Assurance 

*  Other  Pertinent  RemarKS 

SOURCE  of  this  checklist  is:  AFM  4  0  0  -  .5  (  R  )  ,  Attachment  d, 

17  February  1976. 

Negotiations  and  discussions  are  held  between 
the  representatives  of  the  two  countries  to  clarify  the 
requirements  of  Egyptian  Armed  Forces  and  the  assessments 
for  the  acquisition  request.  The  POW  Chief  officer  particip 
ates  in  these  meetings. 

The  fii.al  form  of  the  RLO  is  submitted  to  the 
Defense  Security  Assistance  Agency  (DSAA). 


( 6 )  Provide  Case  Directive .  Upon  receipt  of 
the  acceptance  of  the  LOA,  the  H . Q .  issues  case  directives 
to  the  participating  Major  Commands  and  implementing 
agencies.  The  case  directives  include:  [Ref.  7] 

Financial  aid 

-  Delivery  term  code 

Force  Activity  Designator  (FAD)  or  priority 

-  Purchaser's  service  code 

-  Nonrecurring  cost 

Asset  use  charge 

Sales  commissions  and  contingent  fees 

Any  special  instructions 

(7)  Furnish  Material  or  Services  and  Notify 


therelated  Force  accounting  And  Finance  Center.  (Air  Force 
Example  )  The  major  commands  and  the  implementing  agencies 
that  take  actions  based  on  the  regulations  in  AFM  400-j  are 
[Ref.  6 ] : 


Air  Forces  System  Commands  (AFSC) 

Air  Force  Logistics  Command  (AFCTC) 

Air  Force  Training  Command  (AFTC) 

Tactical  Air  Command  (TAC) 

Air  Force  Accounting  and  Finance  Center  (AFAFC) 

Following  these  actions,  procurement  and 


budget  authorizations  are  obtained 


(8)  Billing  the  Customer.  This 


,  h  e  last 


step  in  the  processing  of  the  foreign  military  sales, 
concerning  the  billing  and  terms  of  payments.  Like  the 


commercial  procurement,  there  are  two  sources  of  f undin r  the 
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government  procurement:  Budget  and  Loans.  The  procedure  Tor 

payment  is  very  similar  to  the  commercial  procurement. 

Conclusion .  The  FMS  procedures  are  complex  and 
lengthy  but  nevertheless  logical  and  structured.  The 
Congress  has  full  control  over  the  procurement  requests 
which  exceed  $  25  million  or  for  Major  Defense  items  that 

exceed  $7  million. 

DoD  implements  the  FMS  through  major  services  using  the 
LOA  D.D.  Form  1513  as  a  contract  document  between  the  USA 
and  the  foreign  country.  This  document  specifies  the  terms 
and  obligations  concerning  the  two  governments  in  processing 
and  implementing  the  procurement  system, 
b.  Spare  Parts  Procurement 

This  kind  of  procurement  is  oriented  towards 
weapons  already  purchased  and  in  the  service  of  the  Egyptian 
Armed  Forces.  The  FMS  system  for  this  kind  of  procurement 
is  divided  into  two  parts:  FMS1  and  FMS2 

( 1  )  FMS  1  .  Represents  an  amount  of  money  paid 

by  the  Egyptian  Government  to  participate  in  sharing  the 
cost  of  the  inventory  of  spare  parts  to  serve  all  countries 
which  have  purchased  weapons  from  USA.  The  FMS1  system  Keeps 
tracx  of  inventory  of  all  kinds  of  spare  parts  ready  on  the 
shelf  to  serve  all  participating  countries.  It  uses  advanced 
scientific  technique  to  prevent  any  shortage  of  spare  parts. 

(2)  FMS2 .  Represents  an  amount  of  money  to 

cover  the  yearly  requisitions  of  the  spare  parts  needed  by 


the  EGAF's.  Requisitions  From  the  system  may  be  done  on  a 
daily  basis  in  a  precisely  structured  computer  format  that 
allow  processing  of  every  single  item  separately.  P 0 W  has 
nothing  to  do  with  the  implementation  of  the  system,  except 
receiving  and  sending  any  related  system  documents  to  both 
sides.  Charges  to  the  system  are  done  by  the  POW  upon 
receipt  of  an  authorized  payment  letter  from  the  AA. 


III.  PROBLEMS  AND  OPPORTUNITIES  IN 


THE  PQW  CURRENT  SYSTEM 


A.  INTRODUCTION 

This  Chapter  identifies  the  problems  and  opportunities 
of  the  POW  relevent  to  developing  a  data  driven  DSS.  In  the 
problem  part,  we  address  the  system  wide  problems  first  and 
then  describe  any  problems  in  each  particular  function,  if 
any.  In  the  opportunities  part  of  this  section,  we  describe 
in  some  details  what  computers  and  databases  can  do  for 
improving  the  existing  functions  of  the  POW  current  system. 
It  should  be  noted  that  the  solutions  for  all  of  these 
problems  will  not  be  covered  in  this  research  because  of  the 
time  constraint;  rather  we  will  emphasize  the  detailed 
design  of  the  commercial  procurement  functions  .  The  inten¬ 
tion  is  to  present  all  the  problems  and  opportunities  of  the 
POW  uncovered  during  interviews  with  the  POW  specialized 
officers. 


B.  SYSTEM  WIDE  PROBLEMS 

The  POW  is  the  central  point  of  receiving  all  the 
requests  of  EGAF's  for  procurement  of  military  items  and 
weapon  systems  from  the  USA.  Because  of  continued  increasing 
demands  from  the  USA,  the  workload  in  POW  is  now  increasing 


exponentially.  The  system  is  designed  to  deal  with  much 
smaller  demand  than  currently  exists. 

The  existing  manual  system  needs  to  be  developed  anu 
supported  by  computer  tools  to  enhance  its  capability.  The 
system  wide  problems  with  the  manual  system  are: 

1.  Too  much  effort  and  time  needed  for  the  manual 
tasks  . 

2.  Some  functions  cannot  be  done  in  a  reasonable  iengtn 
of  time. 

3.  Generating  status  reports  is  getting  more  difficult 
without  computer  tools. 
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C.  COMMERCIAL  PROCUREMENT  FUNCTIONS 
1 .  RF P  *  s  Function 

a.  Problems 

Too  much  effort  and  time  needed  for  the  prepara¬ 
tion  of  vendor  list  for  a  particular  RFP. 

b .  Causes: 

(1)  Large  number  of  RFP's 

(2)  The  RFP  received  is  not  in  a  standard  format  to 
allow  easy  accessing  to  the  vendor  data. 

(  d  )  Large  number  of  vendors  available  in  USA  to  select 
f  r  om . 


c.  Opportunity 


Building  a  database  for  vendor  information 
allows  better  processing  of  the  RFP's  and  decrease  tne 
vendor  selection  time  for  a  particular  RFP. 

2.  RFC  Function 


a.  Problems 

No  problems  are  addressed  in  this  function, 
c.  Opportunity 

A  DSS  can  be  used  as  a  tool  for  evaluating 
proposals  and  vendor  selection.  The  guidelines  to  the  system 
are: 

(1)  Multiple  evaluation  factors  are  established  and 
weighted . 

(2)  Each  proposal  is  scored  by  the  technical  committee 
using  these  factors  . 

( d  )  The  system  should  allow  presentation  of  information 
to  the  evaluators  in  different  formats  including 
graphs  and  utility  analysis. 

3 .  Fund  the  contracts: 

This  part  include  the  both  budget  and  loan  funding. 

a.  Problems: 

Too  much  effort  needed  to  manage  the  funding 

functions. 

b  .  Causes : 

(1)  All  contracts  with  vendors  in  USA  must  be  funded  via 
POW,  a  large  volume  needs  to  be  funded,  over  500 
contracts . 

(2)  Monitor  all  credit  and  guarantee  letters  associated 
with  contracts;  it  represents  large  volume,  over 
1500  of  different  letters  with  different. banks  and 
different  vendors  interacting  in  this  process. 


c .  Opportunity  : 

(1)  This  process  nas  a  potential  for  automation..  An 
automated  system  will  allow  better  control  of  this 
process  by  producing  status  reports  of  ail  tne 
credit  and  guarantee  letters  .  Warning  reports  can 
be  produced  for  renewal  validity  dates  of  the 
guarantee  letters 


(2)  Establish  Financial  management  system  to  monitor 
funds  from  loans,  especially  unused  loans  which  may 
have  a  limited  time  of  validity.  Effective  use  of 
funds  from  loans  depends  on  timely  decisions 
concerning  use  of  this  fund.  The  decision  process 
related  to  the  effective  use  of  available  loans  is 
very  important  to  the  EGAF's.  POW,  as  a  front  office 
can  assist  the  AA  by  producing  status  and  comparison 
reports  of  the  fund  availability  from  loans.  Passing 
this  information  to  AA  ahead  of  time  to  take  the 
necessary  actions  before  the  end  of  validity  date  is 
very  important.  This  one  benefit  of  the  system  may 
cover  many  times  the  cost  of  building  the  system. 

4 .  Administer  open  contracts 

a.  Problems 

All  the  problems  of  any  manual  system  are 
figured  in  this  system  to  some  degree  or  another.  High 
volume  of  paper  work,  slow,  data  redundancy  ,  spending  more 
time  and  effort  to  do  the  function,  etc. 

b.  Causes 

The  problems  in  this  function  are  due  to  the 
fact,  that  the  manual  system  lacks  the  capability  of  the 
computer  system  with  respect  to  the  routine  and  repetitive 
work.  The  POW  staff  tries  to  keep  the  system  running  by 
spending  more  effort  and  time.  The  four  su b- f u nc t i o n s  of  the 
open  contract  adminstration,  payment,  shipment  monitoring 
personnel  training,  and  reporting  form  four  sub-systems 
which  have  a  great  potential  for  automation. 


c.  Opportunity 


( 1 )  Payment  .  The  payment  process  involves  the 
tecnnicai  and  financial  checking  and  validation  based  on  the 
contract,  invoice,  shipment  receipt,  necessary  certificates, 
vendor  performance  etc.  Everything  must  be  checked  before 
payment  is  made.  To  speed  up  the  decision  related  to  tnis 
function,  a  computer  tool  is  a  must.  By  developing  such  a 
system,  the  specialized  officer  can  easily  validate  the 
payment  documents.  In  the  design  chapter  we  present  a 
proposed  system  for  these  functions. 

( 2 )  Monitor  Shipment  of  Items  to  the  Country. 
POW  has  an  access  terminal  to  the  Freight  Forwarder 
computer.  This  system  can  be  improved  by  allowing  transfer 
of  tne  summary  data  about  the  shipment  status  to  the  FOCUS 
database.  This  function  is  included  in  this  research  and  may 
be  expanded  later. 

(3)  Monitor  Personnel  Training.  A  considerate 
amount  of  work  needs  to  be  done  by  the  POW  to  monitor  the 
training  of  personnel.  All  open  contracts,  commercial  or 
government  procurement,  have  a  training  part  which  needs  to 
be  scheduled  on  time.  POW  must  inform  AA  ahead  of  time  of 
the  training  plan  associated  with  each  contract  to  nave 
enough  time  for  selecting  and  preparing  personnel  who  will 
attend  the  training  programs  in  the  USA.  On  the  other  hand, 
all  personnel  affairs  in  the  USA  are  the  responsibility  of 
POW  e.g.  monthly  salary,  traveling  reservation  and  tickets, 


and  medical.  This  function  can  also  be  automated.  The 
database  allows  easy  system  development  of  such  functions  to 
monitor  and  control  all  training  in  USA. 

( 4 )  Reporting .  A  database  system  is  a  powerful 
tool  for  generating  different  kinds  of  reports.  In  PC/FOCUS, 
the  reporting  facility  is  excellent.  It  allows  user  to 
generate  any  kinds  of  reports  they  need  from  the  database  in 
seconds  without  programming.  The  reporting  and  graphics 
facilities  in  PC /  FOCUS  provide  a  valuable  DSS  tool  i'or 
presentation  of  information. 

5 .  Generate  Vendor  List 

This  function  is  necessary  for  the  RFP's  function. 
We  separate  it  here  because  of  its  special  importance.  We 
have  to  deal  only  with  potential  vendors  in  the  USA 
industry. 

a.  Problems 

The  manual  vendor  list  is  time  consuming,  for 
example,  135,000  US  manufactures  are  exist  in  Thomas 
Register,  over  500  vendors  have  contracts  with  POW. 

b.  Causes 

Many  sources  are  used  to  generate  a  vendor  list: 
vendors  who  already  have  contracts  with  POW,  vendors  suggest¬ 
ed  by  AA  for  a  particular  RFP,  vendors  responding  to  an 
advertisment  in  the  newspaper,  vendors  responding  to  RFP's, 
vendors  supplier  to  the  USA  Army/Navy/Air  Force,  and  vendors 


from  Thomas  Register  catalog.  The  investigation  process 
requires  much  time  to  check  the  Qualification  Form  and 
verify  it  from  market  research  associations, 
c.  Opportunity 

The  potential  for  automation  is  very  nigh. 
Putting  vendor  information  in  a  database  is  essential  for 
the  POW  function.  The  cost  of  selecting  bad  vendors  is  much 
higher  than  the  expected  cost  to  develop  any  system  to  keep 
and  maintain  information  about  vendors.  POW  has  a  major 
responsibility  in  selecting  and  validating  vendors  before 
passing  their  proposals  to  AA ,  even  those  suggested  by  the 
AA  with  a  particular  RFP.  vendor  selection  criteria  must  be 
applied  in  all  the  procurement  phases.  Creating  a  database 
for  vendors  will  allow  the  specialized  officer  to  prepare 
the  vendor  list  in  a  fraction  of  time  needed  for  the  manual 
system . 

D.  GOVERNMENT  PROCUREMENT 

As  we  mentioned  in  describing  this  process,  POW  acts  as 
a  co-ordinator  between  AA  and  USA  administration. 

1.  Procurement  steps  for  the  major  Weapons  system  The 
Government  procurement  cycle  is  mainly  done  inside  the  AA 
and  the  USA  administration.  POW  serves  essentially  as  a 


communication  link  between  the  two. 


a.  Problems: 

(1)  How  to  speed  up  the  process  from  submitting  the  RLC 
until  we  get  the  LOA  ? 

(2)  How  to  monitor  the  performance  of  the  Egyptian  Major 
Weapons  System  Contracts  (EGWSC)  managed  by  the  USA? 

b .  Causes: 

(1)  The  FMS  procedures  are  complex. 

(2)  A  network  of  interrelationships  are  involved  in  the 

FMS  process  including  the  President  of  USA, 

Congress,  and  many  Departments. 

(  j )  Inside  DoD,  many  H.Q.  commands  are  involved  in 
processing  a  particular  RLO.  Many  rules  and 
procedures  must  be  followed. 

c.  Opportunity 

Weapons  Acquisition  is  very  critical  function  to 
Egypt.  Getting  the  necessary  defense  weapons  is  of  vital 
importance.  The  time  to  process  the  RLO  is  far  toolong. 
Monitoring  implementation  of  weapons  system  projects  is  very 


important 


Building  a  decision  support  and  monitoring 


system  will  be  of  a  great  help  in  answering  the  above  two 
questions.  POW  is  the  most  suitable  organization  to  do  this 
function,  because  of  its  position  as  a  co-ordinator  or  iinK 
between  the  EGAF's  and  the  USA  administration.  Two  database 
may  be  needed,  one  for  the  acquisition  phase  i.e.  the 


activities  starting  from  submitting  the  RLA  until  getting 


the  LOA. 


The  other  is  for  the  implementation  phase  to 


monitor  all  the  current  projects  managed  by  USA  administra¬ 
tion  for  the  benefit  of  Egypt.  These  two  sub-systems  will 
be  of  great  help  in  speeding  up  the  acquisition  process  by 
pointing  up  any  delay,  and  by  providing  the  data  needed  by 
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fm 


USA  rapidly.  By  building  an  information  system  to  monitor 
Government  procurement  from  USA,  we  put  a  foundation  of  the 
DSS  in  the  Weapons  Acquisition  System  (WAS),  itself. 
Knowing  the  FMS  policy  and  procedures  are  very  important  in 
building  this  system.  All  the  technical  References  related 
to  the  FMS  system  must  be  available.  Technical  support  from 
USA  may  be  needed  to  build  that  system. 

2 .  Spare  Parts  Procurement 

No  Problems  and  Opportunities  related  to  POW  are 


perceived  by  the  author  in  this  study. 


IV.  SOFTWARE  REQUIREMENT  SPECIFICATION  OF  POW 


A.  INTRODUCTION 

The  objective  of  this  chapter  is  to  analyze  the  informa¬ 
tion  flow  as  presented  in  chapter  II,  and  create  the  soft¬ 
ware  requirement  specifications  for  the  POW  Commercial  Procu¬ 
rement  (POW CP)  system.  The  specification  presented  in  tnis 
chapter  will  emphasize  on  the  creation  of  the  DSS  generator 
for  the  POWCP  database. 

The  DSS  generator  is  a  set  of  of  interpreters  and  data 
creation  utilities.  DSS  tools  are  used  to  build  and 
modify  the  interpreters.  [Ref.  1] 

B.  REQUIREMENT  ANALYISIS  OF  POWCP  PROPOSED  SYSTEM 

The  following  are  the  primary  objectives  of  the  POWCP 
proposed  system  : 

-  Increase  functional  performance  efficiency  of  the 
POWCP  system. 

Assist  decision  making  process  in  the  POWCP  system. 

We  recognized  from  chapter  II  and  chapter  III  that  the 

POWCP  has  a  high-payoff  area  for  decision  support.  To 

capture  the  benefits  of  this  high-payoff,  we  are  going  to 

use  the  Iterative  Design  approach  'Staged  Development'  for 

building  a  prototype  DSS  for  the  POWCP.  The  following  are 

the  e x pa  1  a n a t i o n  of  the  approach  as  presented  in  [Ref.  1  J  : 

DSS  need  to  be  built  with  short,  rapid  feedback  from 
users  to  ensure  that  development  is  proceeding  correctly. 
They  must  be  developed  to  permit  changes  quickly  and 
easily.  The  result  is  that  the  most  important  four  steps 


in  che  typical  systems  development  process  (analysis, 
design,  construction,  implementation)  are  combined  into 
a  single  step  which  is  iteratively  repeated.  The  essence 
of  the  approach  is  that  the  user  and  the  builder  agree 

on  a  small  but  significant  problem,  then  design  and 

develop  an  initial  system  to  support  the  decision  making 
that  it  requires.  After  a  short  period  of  use  (.a  few 
weeks),  the  system  is  evaluated,  modified,  and 
incrementally  expanded.  This  cycle  is  repeated  three  to 
six  times  over  the  course  of  few  months  until  a 

relatively  stable  system  is  evolved  which  support 
decision  making  for  a  cluster  of  tasks.  The  word 

relatively  is  important,  because  although  the  frequency 
and  extent  of  changes  will  decrease,  it  will  never  be 
stable.  The  system  will  always  be  changing,  not  as 
necessary  evil,  but  as  a  conscious  strategy  on  the  part 
of  user  and  builder. 

The  advantages  of  using  this  approach  are:  Leads  to 
development  of  DSS  Generator,  gives  early  success  and 
visibilty,  Allows  overlapping  of  different  staged  DSS 
and  integration  between  them,  ability  to  assimilate 
evolving  technology.  [Ref.  1] 

To  realize  the  benefits  of  this  approach,  we  must  be 
concerned  about  the  time  of  development.  It  should  oe  as 
short  as  possible  (2-3  months  maximum  for  the  first  version) 
prepare  an  action  plan,  for  development,  divided  into  phases, 
build  the  DSS  generator,  use  the  structure  approach  in 
analysis  and  design  of  DSS  to  be  able  to  maintain  and  adapt 
the  system  during  each  stage,  finally  we  should  use  available 
software  as  we  did  in  PC/FOCUS. 

The  approach  used  to  describe  the  proposed  system  is  to 
follow  the  logical  sequence  for  each  function  and  describe 
each  process  associated  with  the  improved  DFD.  The  secondary 
process  for  a  particular  function  is  described  at  the  end  of 
the  function.  Because  our  priority  is  to  build  the  DSS 
generator  first,  i.e.  the  database,  we  first  apply  the  data 


analysis  technique  (See  data  dictionary  section,  chpter  V  .  ; 


to  derive  the  database  structure  in  tnira  normal  form  before 
designing  the  database  file  as  described  in  tae  following 
chapter.  The  disk  media  symbol  used  to  indicate  the  proposed 
database  files.  Only  the  functions  or  processes  to  be 
automated  are  explained  in  the  following  sections. 

1.  RFP  Functions  Description.  The  fuction  is  divided 
into  sub-fuctions  and  process,  expalanation  of  each  one  are 
presented  as  necessary  . 

Process  1.1:Prepare  &  issue  the  RFP.  Figure  4,k 
shows  the-  details  of  tne  process. 

-  Procsessl  .  1  .  1  Receive  &  review  the  RFP.  Figure  4  .  j 
shows  the  premitive  level  of  DFD.  The  following  are  a  walk¬ 
through  for  each  process.  The  same  sequence  of  will  be  used 
to  explaine  the  other  functions 

Process  1  .  1  .  1  ♦  1 _ Register  RFP.  The  purpose  of  tnis 

function  is  to  register  each  particular  RFP  in  the  General 
Log  Book  (GLB)and  the  RFP  Control  Book  (RFPCB).  he  code 
used  to  register  the  RFP,  or  any  incoming  documents  to  P  0  W 
consists  of  a  six  digit  serial  number  starting  at  one  at  the 
beginning  of  the  year  and  incremented  by  one  for  each 
incoming  document.  This  number  will  be  used  as  a  key  when 
recording  the  information  about  the  major  documents  received 
or  issued  from  PUW.  The  information  items  kept  in  the  GLB 
are: 

*  Registration  Number  *  Date  Received 


source  and  subject 


i  h  e  Hr  P  is  ;nen  routed  to  the  ipecia.ized  Jr'rioer 
(SG)  in  the  area  of  specialization. 

Process  1  ■  1  ,  1  ,2 _ Review  and  Checks  RFP  .  The  o 

reviews  and  checks  the  specification.  This  process  is 
subjective  and  relies  on  the  capabilities  of  the  SO. 

Process  1 . 1 . 1  .  3 _ Enter  RFP  in  the  Database.  Enter 

the  RFP  data  in  the  database  through  screens.  The  following 
are  the  data  related  to  a  typical  RFP: 

*  RFP  Number 

*  Received  date 

*  Requester  (Force  or  Department) 

*  RFP  subject 

*  Items  needed 

*  Item  description 

*  Unit  of  Issue 

*  Quantity 

*  Estimated  Dollars  value 

*  Terms  and  conditions 

*  Vendors  who  receive  the  RFP 

*  Vendors  who  send  Proposals  data. 

(Normalization  of  data  will  be  done  in  next  chapter.) 

Process  1.1.2 _ Select  Vendors  to  Receive  RFP . 

Selection  of  vendors  to  receive  tne  RFP  are  done  only  from 
the  qualified  vendor  in  the  Vendor  Database.  Creation  of  the 
vendor  database  is  described  at  the  end  of  this  section. 


(Figure  4.4; 


Figure  4.3  Receive  &  Record  RFP  in  Database 
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particular  RFP's  item  classes  witn  the  item  classes  in  the 
vendor  database.  This  process  is  done  by  the  computer  to 
produce  a  primary  list  of  vendors  who  are  relevant  to  the 
RFP.  The  SO  may  repeat  this  process  using  other  item  classes 
until  he  is  satisfied  with  the  vendor  list  produced.  The 
vendor  list  may  look  as  follows: 


VENDOR  LIST 

RFP-NO: 

VENDOR  VENDOR  POINT  OF  VENDOR  PHONE 

ID  NAME  CONTACT  ADDRESS  NO 


ITEM 

CLASS 


-  Process  1  .  1  .  2 . 2 _ Check  Vendor  Details.  The  SO  may 

wish  to  access  the  detailed  data  about  a  particular  vendor. 
He  can  do  that  by  retrieving  the  vendor  record  using  the 
vendor  ID.  If  he  wants  more  details  about  the  vendor  company 
such  as  its  profile  or  brand  names  etc.,  he  may  refer  to  the 
Thomas  Register  or  any  other  reference. 

Process  1.1. 2. 3 _ Approve  the  Final  Vendor  List . 

The  SO's  must  approve  all  vendor  lists  generated  by  any 
means  (computer  or  manual)  from  the  POW  Director  before 


mailing  it  to  vendors  with  the  RFP  copies. 


Process  1.1.3  Mail  RFP  to  Vendors 


Process  1  .  1  .  3  •  1 


Produce  Vendor  Mailin 


This  process  may  be  done  either  manually  or  by  computer  to 
prepare  the  mailing  label  of  vendor  address  and  point  of 
contact.  (Figure  4.5) 

Process  1  ♦  1  . 3  ♦  2 _ Issue  the  RFP  to  Vendors.  A 

number  of  copies  of  the  RFP  are  produced  using  electronic 

copier  machine  and  mailed  to  the  vendors.  The  information 
about  vendors  who  get  the  RFP  is  recorded  in  the  computer 
and  the  RFPCB.  The  following  is  the  data  structure  of  the 
RFPC3  to  be  recorded: 

*  RFP  Number 

*  RFP  Copy  Number  (a  serial  number  within  RFP 

*  Vendor  ID 

*  Vendor  Name 

*  Date  of  Issue  to  Vendors 

Process  1.2  Receive  Proposals. 

Process  1.2.1  Receive  and  Record  Proposals. 

Process  1  ,  2  ■  1 .  1 _ Register  Proposals .  All  incoming 

proposals  are  registered  in  the  GLB  and  RFPCB.  A  register 

number  is  given  to  each  proposal  in  the  GLB.  The  data 
elements  to  be  recorded  are: 


RFP  Number 


Proposals  Serial  Number 


Vendor  Name 


*  Date  of  Received 


Proposals  description 


% 


4J* 


i  Select  j 

|  Vendors  i 

;  to  Receive  |~ 

!  RFP 


Approved 

Vendor 

List 


1.1.3  Mail  RFP  to  Vendors 
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DATABASE 


/  1.1. 3.1 
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Vendor 
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j  Prepare  |  I  Mail 

i  the  Requirodj  RFP’s  j  List 
I  RFP  Copies  Copies  | 


•V  RF 


VENDOR 
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Data 


D2/  1  RFP  CONTROL  BOOK 


Figure  4.5  Mail  RFP  to  Qualified  Vendors 


Process  1  .  2  .  1  .  2 _ Check  and  Review  Proposals .  The 

30  reviews  and  checks  all  the  incoming  proposals.  The 
proposals  from  new  vendors  are  put  in  a  pending  file  until 
the  qualification  process  is  done.  The  non  relevant 
proposals  and  the  non-qual i f i ed  vendors  proposals  are 
discared.  The  relevant  proposals  from  the  qualified  vendors 
are  put  in  a  pending  file  until  closing  date  of  RFP  is  over. 

Process  1 . 2 . 1 . 3 _ Record  Proposals  .  The  basic 

proposals  data  are  recorded  in  the  Proposals  Monitor  File 
CPMF).  The  data  to  be  recorded  are: 

*  RFP  Number 


*  Proposals  Serial  Number  (within  the  RFP  number) 

*  Vendor  Name 

*  Vendor  ID 

*  Proposals  Received  Date 

*  Total  Value  Of  Proposals 

Process  1.2.2 _ Issue  Qualification  Form.  (QF) 

QF's  are  issued  to  new  vendors.  Their  proposals  are  put  in  a 
pending  file  until  the  investigation  is  completed. 

Process  1.2.3 _ Produce  List  of  Received  Proposals. 

After  the  closing  date  is  over,  a  certain  program  in  the 
computer  is  triggered  to  match  the  RFP  Monitor  File  with  the 
Proposals  Monitor  File  and  produce  a  report  of  all  received 
proposals.  The  matching  key  is  the  RFP  Number  in  both  files. 
This  list  with  the  physical  copies  proposals  are  forwarded 
to  A  A . 

6  9 


/  i 


_  s  t  n  e  suggested 


PROPOSALS  LIST 


RFP 

NUMBER 


PROPOSAL 

NUMBER 


VENDOR 

NAME 


DATE  TOTAL 

RECEIVED  VALUE 


2.  RFC  Function  Description 


The  potential  for  automation  of  this  function  is  not 
too  high  because  it  is  not  the  common  case  for  the  POW  to  do 
the  contracting  with  vendors,  except  for  small  contracts. 
This  function  has  high  potential  as  a  future  DSS  application 
for  evaluating  proposals  and  vendor  selection,  but  the 
volume  of  RFC  is  not  big  enough  in  POW  to  be  included  in 
thisthesis. 

The  manual  system  of  the  RFC  function  will  not  be 
changed,  except  recording  basic  RFC  data  to  produce  status 
reports.  Figure  4.7  shows  how  the  RFC  function. 

The  data  structure  of  the  RFC  is: 

*  RFC  Number  (Register  number) 

*  Date  Received 

*  RFP  Number 

*  Requester  (Force  or  Department) 

*  RFC  Subject 

*  Fund  Letter  Number 

*  Fund  Dollar  Amount 


2 . 1  Process  RFC 


ii  di 


VENDOR  DATABASE 


Irjc 


2.1.1 


Register  the 
RFC  in  6en. 
Book 


AO 


RFC 


2.1.2 


Check 

RFC 


Vendoif 
Data 


SO 


y 


Subj.  & 

Date  Received 


GLB 


Completed! 
,RFC 


2.1.4 


Prepare 
Appointemenl  Contract 

Implement. 
Plan 


RFC 


Letters 


2.1.3 


AO 


Determine! 

i 

of  Fund  1 


RFC  no 
Date. 
Time 


■D12 


FO  j 

"4  Source. 
Amount 


FUND  SOURCE  ijlLF 


D  1 3 


CONTRACT  IMPLEMENTATION  PLAN 


T 


NAMES 


OfficerHames 


2.1.5 


Form  Nego 
Team 


-C 


Officers  work  File 


POW  C. 


POW 


Vendor(s)  Best  and  Final  Offers 


*  Technical  Evaluation  Ranking 

*  Negotiation  Base  (Least  Cost  or  Price  Performance 
Ratio) 

j .  Funding  Contracts 

The  funding  contract  function  is  also  small  because 
it  is  limited  only  to  commercial  contracts  signed  in  PQW. 
Like  the  RFC  it  is  not  big  enough'to  be  automated.  For  chat 
reason  this  function  will  not  be  changed,  except  the 
management  of  the  guarantee  letters  of  all  contracts  signet 
with  US  vendors  either  in  Egypt  or  in  POW,  currently  about 
1500.  This  sub-  function  has  great  potential  for  automation 
because  the  Guarantee  Letters  ’must  be  monitored  by  POW.  This 
sub-  function  will  be  developed  as  a  part  of  the  Administer 
Contract  function. 

4 .  Administer  Open  Contracts 

By  developing  this  function  we  could  increase  the 
efficiency  of  POW.  The  basic  data  about  a  particular 
contract  must  be  recorded  in  the  Contract  Database  File 
(CDF).  The  data  structure  of  the  contracts  is: 

*  Department  Code  (2  Characters) 

*  Contract  Number  (Serial  number  within  department 
code) 

*  Contract  Name  (Heading  of  50  characters  ) 

*  Contract  Description  (TEXT  of  50  characters) 

*  Contact  Vendor  Name 
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-V. 


*  Contract  Vendor  ID 

*  Contract  signed  date 

*  Contract  Total  Value 

*  Contact  Items  (Repetitive  group) 

*  Unit  of  Issue  UI 

*  Quantities 

*  Contract  Summary 

*  Inspection  Schedule 

*  Payment  Schedule 

*  Shipment  Schedule 

*  Training  schedule 

*  Basic  Attached  document 

*  Guarantee  letters 

*  Source  of  fund  letter 

*  Case  designator  (fo r  the  loan  funded  contracts) 

*  Certificates 

The  following  are  the  sub-functions  to  be  automated: 

a .  Payment 

b.  Monitor  shipment 

c.  Monitor  Personnel  Training  related  to  contracts 

d.  Monitor  Guarantee  letters 

e.  Reporting 
a.  Payment 

The  contracts  are  sorted  into  groups  according 


the  specialized  area. 


Each  specialized  officer  is 


4.1  Payment 


responsible  for  one  or  more  groups.  The  database  for  cue 
contracts  must  be  centralized.  The  data  about  contracts  can 
be  retrieved  and  updated  through  the  computer  terminal.  The 
following  are  details  of  the  payment  process:  (Figure  4.3. 

Process  4.1.1 _ Register  the  Payment  Documents .  The 

payment  documents  are  received  and  registered  in  the  GLB 
then  routed  to  the  specialized  officer.  The  payment 
documents  consist  of  the  original  invoice,  the  shipment 
receipt  from  the  Freight  Forwarder  (FF),  and  tne  certific¬ 
ates  of  manufacture  and  warranty. 

Process  4.1.2 _ Review  and.  Check  The  Payment 


Documents 


The  specialized  officer  accesses  the 


contract  database  and  contract  monitor  file  to  check  the 
documents  against  the  previous  payments,  shipment  schedule, 
etc.  to  be  sure  of  meeting  the  requirements  of  contract.  n 
pre-defined  report  may  be  produced  to  assist  him  in  doing 
his  job.  The  following  is  the  suggested  report  format: 


SHIPMENT  HISTORY 

CONTRACT  SHIPMENT  TOTAL  DATE 

NUMBER  NUMBER  VALUE  RECEIVED 

The  specialized  officer  can  also  retrieve  detail¬ 
ed  information  about  a  particular  contract  or  vendor  to 
assist  him  in  making  his  decision  to  approve  the  payment. 

The  SO  will  be  authorized  to  record  the  data 


about 


shipment  notice  and  the  certificates  related  to  his 
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contract  group  area.  The  following  is  the  data  structure  of 
the  shipment  notice: 


w 


i 


K+ 


Ifiy 


* 

Contract 

Number 

ft 

Shipment 

Number 

ft 

Shipment 

Date 

ft 

Shipment 

Value 

ft 

Shipment 

Items  (Repetitive 

*  Name 

*  Unit 

of  Issue 

*  Quantity 

ft 

Vendor  ID 

ft 

Shipment 

data 

The  SO  approves  the  payment  and  forwards  tne 
payment  documents  to  the  Financial  Officer  (FO). 

Process  4.1.3  Check  The  Payment  Documents  By  The  FO 
•The  FO  checks  all  the  payment  documents  paying  special 
attention  to  the  validity  of  the  invoice.  He  will  be  able  to 
produce  reports  of  all  the  payment  information  about  a 
particular  contract  or  vendor.  He  can  also  produce  reports 
about  the  status  of  fund  availability.  The  following  is  the 
suggested  report  format: 


PAYMENT 

HISTORY 

CONTRACT 

INVOICE 

DATE 

TOTAL 

NUMBER 

NUMBER 

RECEIVED 

VALUE 

9b 

The  FO  is  the  only  officer  authorized  to  record  the 


b.  Monitor  Personnel  Training 
Process  4.2 _ Monitor  Personnel 

personnel  training  sub-function  is  very 


i 

t 


Training. The 
important.  Two 


processes  are  related  to  the  training:  preparation  and 
implementation  of  the  training  plan  and  following  up  of 
personnel  during  the  training  period  in  USA. 

Process  4.2.1 _ Pepare  Training  Plan.  After  signing 

the  contract  the  training  information  is  extracted  from  the 
contract  and  recorded  in  training  database.  The  data 
structure  for  the  training  data  are: 

*  Contract  Number 

*  Line  number  related  to  training  in  the  the 
contract 

*  Number  of  personnel  to  be  trained 

*  Pre-request  for  training  (repetitive  group) 

*  Training  Period  (repetitive  group) 

*  Location(s)  (repetitive  group) 

*  Estimated  Date  of  training  (Repetitive 
group ) 

*  Actual  Date  of  Training 

-  Process  4.2.4 _ Personnel  Affair  in  Training  The 

PQW  becomes  responsible  for  all  officers  under  training 
along  the  period  of  staying  in  the  USA.  The  Administrative 
Officer  in  POW  is  responsible  for  preparing  the  monthly 
payment  for  all  officers,  mailing  them  the  checks  every 
month,  travel  reservations,  internal  transportation  during 


check  in/out  in  USA,  and  medical  care. 


Figure  4.9  Monitor  Shipment 


Course  Number 


Course  Description 


» 

*  Training  Period 

*  Start  Date 

*  End  Date 

*  Monthly  payment  rate 

The  number  of  personnel  may  not  exceed  200  officers 
on  average  any  time  during  the  year.  The  automation  of  this 
function  is  not  included  in  this  thesis  because  of  the  time 
constraint . 

c.  Monitor  Shipment 

Process  4.3  Monitor  Shipment  of  Items  to  Egypt. 
The  Freight  forwarder  (FF)  is  contracted  to  do  this 
function.  The  POW  shipment  officer  has  an  access  terminal  to 
the  FF  computer.  No  potential  for  automation  is  recognized 
for  this  function.  The  manual  function  will  stay  without 
change  as  presented  in  chapter  II. 

d.  Monitor  Guarantee  Letters 

Process  4.4  Monitor  Guarantee  Letters.  The  total 
number  of  active  guarantee  letters  may  exceed  1000  with  a 


|  total  value  over  $10  million.  Keeping  track  of  these  letters 


* 


is  very  important.  The  proposed  system  is  a  warning  system 
to  prevent  losing  the  guarantee  letters  after  they  exceed 
their  validity  periods.  The  software  requirement  for  this 
function  is  simple.  All  the  Guarantee  letters  are  recorded 
in  a  database  file.  A  printed  list  is  produce  every  week  of 


the  guarantee  letters  that  need  to  be  renewed.  This  list 


b 
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Figure  4.10  Monitor  Personnel  Training 


is  produced  far  enough  ahead  to  allow  enough  time  for 
requesting  the  renewal.  The  data  structure  for  the  guarantee 
letters  is: 

*  Contract  Number 

*  Guarantee  Letter  number  (within  the  Contract 
number ) 

*  Bank  issued  from 

*  Vendor  ID 

*  Vendor  Name 

*  Total  V  alue 

*  The  purpose  of  the  guarantee  letter 

*  Starting  Date  of  Validity 

*  Ending  Date  of  Validity 
e.  Reporting 

Process  4.5  Prepare  Reports.  The  reporting 


facility 

of 

the  PC/FOCUS  database  is 

very  powerful  and 

can 

be  used 

to  generate 

any 

reports 

needed 

by  POW.  In 

chapter 

II 

we  presented 

only 

the 

general 

kinds 

of  reports  that  may 

b  e 

produced. 

In 

this 

Chapter ,  we 

inroduce  specific 

reports 

to 

be  generated  . 

It 

i  s 

not  necessary 

that  all 

reports 

be 

printed  ; 

most 

o  f 

them 

may  be 

needed  only  as 

a  screen 

displays. 

PC/FOCUS 

has 

the  facility 

to  view  the 

report 

on 

the  screen  first.  If  the  user  needs  to  print  it,  he  can  then 
issue  two  commands:  OFFLINE  to  let  PC/FOCUS  forward  the 


output  to  the  printer  and  RETYPE  to  repeat  the  document. 


The  following  are  a  list  of  the  proposed  reports: 


( 1 )  The  status  Reports: 

-  Vendor  Status  Report 
RFP/Proposals  Report 
Department/ RFP  Report 

-  Department/Contract 
Vendor  /  Contract  Report 

-  Department  /  Vendor 
Vendor  /  Department 

( 2 )  Progress  Reports  : 

Contract  implementation  over  a  period  of  time  ay 
the  value  received. 

Shipment  of. items  over  a  period  of  time 

-  RFP  Received  and  processed  during  a  period 

( 3 )  Comparison  reports: 

These  kind  of  reports  are  very  important  for 
decision  support.  Mainly  it  can  be  used  during 
evaluation  functions.  The  financial  modeling 
function  of  PC/FOCUS  can  be  used  to  produce 
these  kind  of  reports.  The  graphic  terminal 
system  nay  be  used  for  the  graphic  presentation 
of  these  reports. 

5 .  Generate  Effective  Vendor  Database 

We  need  to  build  an  effective  vendor  database  for 
the  potencial  and  qualified  vendors  who  are  most  suitable  to 
be  supplier  for  the  Egptian  Armed  Forces.  This  function  has 


a  highly  payoff  compared  with  the  other  functions  because 
it's  relatively  simple  to  implement  on  the  computer  and  a 
great  effort  is  needed  in  the  manual  system  to  prepare  tne 
vendor  list  for  a  particular  RFP.  It  may  take  more  than  a 
week  to  prepare  a  vendor  list  for  a  particular  RFP. 

In  the  USA  there  are  over  1  j  5  ,  0  0  0  manufacturers.  ,1  e 
cannot  practically  put  all  the  qualified  vendors  in  USA  in 
our  database,  otherwise  it  becomes  very  big.  The  practical 
approach  to  building  an  effective  vendor  Ddtabase  for  PGW  is 
to  include  initially  only  vendors  who  already  have  contracts 
With  POW.  We  can  then  add  the  RFP-  driven  vendors  to  it  i.e. 
all  vendors  who  offer  accepted  proposals.  Periodically,  the 
vendor  database  is  reviewed  and  non-active  vendors  are 
dropped.  Other  sources  of  potential  vendors  may  be  used  such 
as:  USA  Armed  Forces  and  Government  suppliers,  and  Thomas 
Register . 

The  following  is  the  data  structure  for  a  specific 

vendor: 


Vendor  ID  (A  local  code  is  used  with  a  cross- 
reference  table  for  vendor  code) 

Vendor  Name 

Vendor  Point  of  Contact 


» 


Vendor  Address 


Phone  Number 


» 

*  Telex 

*  Business  Assec  Rate 

*  Business  Start  Date 

*  Business  Activities  (Repetitive  group) 

*  Vendor  Item  Classes  (Repetitive  group) 

*  Vendor  Department  Area 

*  Vendor  Supplier  to  USA  Armed  Forces 

*  Vendor  Previous  Relation  with  p  0  W 

*  Vendor  Rating  Grade 

C.  CONCLUSION  OF  THE  CHAPTER 

This  chapter  was  very  important  because  all  the 

necessary  information  to  buxld  the  new  system  are  now 

available.  Each  function  is  analyzed  to  determine  whether  or 
not  be  automated,  The  data  elements  for  each  function  is 
determined  also,  the  revisited  DFD's  are  used  to  explain  the 
system.  The  data  dictionary  section  is  moved  to  the  next 
chapter  to  integrate  it  with  the  design  issues  for  the  new 
system.  Figure  4.11  shows  the  logical  relations  between  the 
Entities  of  the  system,  the  lines  with  arrows  represent  a 

one  to  many  relationship  between  the  entities.  In  the 

designed  system  an  entity  may  be  divided  into  one  or  more 


database  file. 
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Figure  4. 1  1  Logical  Relations  Between  Entities 


V.  SOFTWARE  DESIGN  OF  POWCP  SYSTEM 


A.  OBJECTIVES 

DSS  consists  of  three  major  components,  a  data  base,  a 
model  base,  and  a  dialog  components.  The  objective  of  the 
software  design  is  to  build  the  data  base  components,  the 
most  important  components  in  DSS. 


The  DBMS  is  one  of  the  three  major  components  of  a  DSS. 
(The  other  two  components  are  the  dialog  component  and 
the  model  component.)  A  DBMS  is  an  important  tool  for 
building  a  DSS,  and  a  poor  data  base  management 
.  component  can  cause  the  failure  of  a  DSS.  LRef.  1] 

The  software  we  use  is  the  PC/FOCUS  which  allows  easy 

building  of  the  other  two  components  as  well.  The  POWCP 

system  attempts  to  aim  at: 

1.  Improving  the  performance  of  POW  in  the  Commercial 
Procurement  system  by  providing  the  right  inform¬ 
ation  at  the  right  time  to  the  right  person.  The 
result  of  the  system  must  affect  the  RFP  function  by 
reducing  the  time  for  preparing  the  list  of  vendors 
who  are  qualified  to  receive  a  particular  RFP  and 
improving  the  capability  of  POW  to  administer  the 
open  contracts . 

2.  Introducing  automated  assistance  to  improve  decision 
making  in  POW. 

B.  DATABASE  STRUCTURE 

1.  Database  File  Relation 

The  following  are  the  database  file  relations  that 
show  the  primary  key  fields  in  each  file  "underlined" 
and  the  other  fields  which  are  used  for  linking  the  file  in 


the  database . 


PQWDEP ( REQ-ID , 


•  •  • 


) 


s 


K 


K 


PQWRFP ( RFP-NO ) , DEP-ID,  ...) 

POWRFCC  RFC-NO , RFP-NO , DE PART-NO  1  ,  ...) 

POWVNDR( VENDOR-ID, DEPCUSTOMER,  ...) 

POWCONTRC  CONTR-NO , CONTRACT-PEP , CONTR AC T-VID ,  .  .  .  ) 

POWBANKC  BANK-NO .  ...) 

POWINVOI ( IN  VOICE-NO , INV-CONT-NO , IN V-VNDR-ID , IN V-CHEC K-NO , 

.  .  .  ) 

POWORDR ( P AYORDER-NO , PAY-O-INV-NO , PA Y-ORD-BANK  ,  .  .  .  ) 

POWCHECK(  CHECK-NO, CHECK- INV- NO .CHECK-BANK,  ...) 

POWICLASC VENDOR-ID  1 , VNDR-ITEM-C ,  ...) 

POWVDEP(VENDOR-ID2,VNDR-DEP-NO,  ...) 

POWSHIPN (SHIP-NOTICE, SH IP -CQNT-NQ,SHIP-INV-NO,  .  .  .  ) 
POWCITEMC  CONTR-NO 1 , ITEM-CODE  ,  .  .  .  ) 

POWBNKAC( BANK- NO , BANK- AC  CO U NT ,  .  .  .  ) 

2.  Database  Schema 

Figure  5.1  shows  the  relations  between  the  database 
files.  Notice  that  the  first  five  files  represent  the 
commercial  procurement  cycle  until  signing  of  the  contract. 
The  rest  of  the  files  represent  the  administration  contract 
function.  The  connection  between  the  two  groups  is  done  via 
the  contract  file.  This  structure  provides  the  most  simple 
way  of  building  the  database.  The  key  fields  are  underlined 
and  the  other  fields  are  used  to  connect  the  different  files 
which  can  be  done  easily  by  the  join  facility  of  PC/FOCUS. 
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no 


From  this  structure  we  can  generate  many  of  the  iogica 


structure  to  produce  the  required  reports. 


C.  DESIGN  IMPLEMENTATION  ISSUES 
1  .  Data  Dictionary 
a.  Normalization 

Since  we  are  going  to  build  the  DSS  generator  of 
POWCP  system,  the  database,  normalization  of  data  is  very 
important  as  a  necessary  logical  step  before  undertaking  the 
physical  design  of  the  database.  One  of  the  objectives  of 
normalization  is  to  get  the  simplest  possible  representation 
of  data  that  we  can  get.  In  other  words,  remove  the  complex 
relationships  between  data  structures  by  removing  repeating 
groups  (first  Normal  Form  (INF)),  group  all  nonkey  data 
elements  in  a  structure  to  be  fully  functionally  dependent 
on  a  single  primary  key  in  the  same  structure  (Second  Normal 
Form  (2NF)),  and  remove  all  the  nonkey  data  elements  which 
are  functionally  dependent  on  other  nonkey  data  element  in 
the  same  structure  (Third  Normal  Form  (jNF)).  The  reasons  to 
do  data  normalization  before  designing  the  physical 
database  are:  a.  Construct  the  simplest  possible  data 

structure  before  loading  the  database  because  it  is 
difficult  to  change  the  structure  of  the  database  after 
loading  the  actual  data  to  the  system  (although  PC/FOCUS 
allows  data  base  rebuilding  via  the  REBUILD  COMMAND  which 
allows  reorganizing,  reindexing,  and  rebuilding  damaged 


1  1  1 


FOCUS  files);  b.  Normalization  prevents  deletion  anomalies 

which  means  that  we  may  lose  facts  about  two  entities  by  one 

deletion.  For  example  if  the  item  class  only  exists  in  the 

vendor  record,  if  only  one  vendor  supplies  this  item  class 

and  this  vendor  does  not  exist  in  our  database,  the  item 

class  also  will  not  exist.  Normal! zation  also  prevents 

insertion  anomalies  which  constrains  inserting  an  entity 

unless  another  logically  unrelated  entity  is  also  inserted. 

Both  for  the  manual  and  for  computer  systems,  it  usually 
is  easier  and  cheaper  to  change  the  logic  of  a  process 
than  to  change  the  structure  of  a  data  store. 

Consequently,  the  simpler  and  more  general  the  structure 

of  a  data  store,  the  easier  and  cheaper  it  will  tend  to 
be  to  make  changes  in  the  data.  [Ref.  31 

b.  RFP  Structure  Normalization  (An  Example) 

The  Request  For  Proposals  (RFP)  data  structure 
will  be  used  as  an  example  to  apply  the  normalization 
technique.  For  the  other  data  structures,  we  present  the 
final  result  in  3NF  with  the  proper  names  that  will  be  used 
in  the  physical  design  of  the  database. 


RFP  Data  Structure:  (Not  normalized) 

-  RFP  Number 
Date  Received 

-  Requester  Code  (Force  or  Department) 

+  -  Requester  Name  (Two  character  code) 

-  RFP  Sub j  ect 

*  -  Items  Needed  (Repetitive  group) 

*  -  Item  Name 

*  -  Unitoflssue 

*  -  Quantity 

*  -  Items  Class  (key  words  such  as:  Tools, 

Engines , Pumps  ,  Computers, 

etc  .  ) 

-  Estimated  Dollars 

-  Source  of  Funds  (Budget,  Loans,  Others) 

*  -  Suggested  Vendor  Names  (Repetitive  group) 

The  data  marked  with  are  repeating  groups. 

The  data  .  elements  marked  by  are  not  functionally 

dependent  on  the  RFP  number.  No  data  elements  functionally 
dependent  on  other  data  elements  appear  in  the  RFP  data 
structure.  To  do  the  normalization,  first  we  separate  the 
repeating  groups  as  follows: 


RFP  Data  Structure 


(INF) 


-  RFP  Number  (Key  data  element) 

Date  Received 

+  -  Requester  Code 
+  -  Requester  Name 

-  RFP  Subject  RFP  Number 

Items  Needed 
Item  Name 
Unit  of  Issue 
Quantity 

RFP  Number 
Item  Classes 

-  Estimated  Dollars 

-  Fund  Source 

RFP  Number 
Sugg.  Vendor  Name 

Second,  we  separate  the  data  elements  marked  by 
" + "  and  leave  the  Requester  Code  to  link  the  two  data 
structures  as  needed.  The  following  is  the  data  structure 
in  2 NF  : 
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RFP  Data  Structure 

RFP  Number 
-  Date  Received 
Requester  Code 


(2NF) 

(Key  data  element) 

Requester  Code 
Requester  Name 


RFP  Subject 


Estimated  Dollars 
Fund  Source 


RFP  Number 
Items  Needed 
Item  Name 
Unit  of  Issue 
Quantity 
RFP  Number 
Item  Classes 


RFP  Number 
Sugg.  Vendor  Name 

The  above  structure  is  in  third  normal  form.  We 
notice  that  the  original  RFP  data  structure  is  divided 
physically  into  six  normalized  data  structures.  These 
structures  can  be  logically  grouped  together  to  form  the 
original  data  structure  or  any  other  structure  as  required. 
In  the  following  page  the  new  six  data  structure  are 


presented . 


POWRFP  FILE: 

»RFP_NO 

RF  P_D A T E 

♦REQ_ID 

R F  P_S U  B J  ECT 

RF  P_CQMMENT 

POWREQ  FILE: 

•REQ-CODE 

REQ-NAME 

RFPITEM  FILE: 

♦  RFP_NO  1 

♦ITEM_CODE 

UNI T_OF_I SS  U 

QUANTITY 

RF  P I C  LAS  FILE: 

ITEMCLAS 

+RFP_NO 

*ITEM_CLASS 

♦ITEM_CLA3S 

SPECF I  CAT  ION 

SUGVNDR 

FILE: 

-*•  RF  P_NO 

♦VENDOR 

ID 

The  new  structure  of  the  RFP  data  structure  is  divided 
into  six  files  which  are  in  the  3NF  an-d  prev-ent  deletion  or 
insertion  anomalies  as  we  can  see  from  the  RFPICLAS  and 
ITEMCLAS  files.  We  notice  that  the  key  fields  are  identified 
by  which  means  only  one  occurrence  is  allowable  for  each 

value  of  a  key.  These  fields  must  be  indexed  to  allow  joins 
between  other  records  of  the  same  values  in  PC/FOCUS.  The 
fields  identified  by  " + "  means  that  these  fields  can  be  used 
for  joins  between  records.  Combining  two  fields  of  type 
form  a  key  of  type  " * "  which  uniquely  identifies  one 
occurrence  of  a  record. 

c .  File  Structure 

The  following  are  the  database  record  descrip¬ 
tions  which  are  produced  using  the  PC/FOCUS  Filetalx 
utility.  The  Filetalk  utility  allows  the  user  to 
interactively  create  Master  File  Descriptions  (MFD).  All 
MFD's  are  described  as  a  single  record  (segment).  Each 
record  contains  a  group  of  relevant  data.  Notice  that  every 
name  of  a  record  is  preceded  by  the  procurement  office 
initials,  POW,  to  allow  easy  recognition  of  the  files  and 
prevent  it  from  accidental  deletion.  Note  that  the  key  field 
of  each  record  is  marked  by  " * "  at  the  beginning  of  the 
line.  The  other  key  fields  which  may  used  for  joining  the 
files  are  underlined. 


FILEMAME:POWDEP , SUFFIX :FOC 


(Force  or  Department  File) 


SEGNAME:ONE,SEGTYPE:S1 

«FIELDNAME  =  DEPART  ID,  Ai.IAS  =  DEP,  FORMAT: A2 , F IELDTYPE= I  , 
F i E  L  D  N  A  M  E - D  E  P  A  R  T_  N  A  M  E ,  ALIASsDEPN,  FORMAT=A25, 

FILES AM E=POWRFP,SUFFIX=FOC  (Request  For  Proposals) 

3EGNAME=0NE,SEGTYPE=S1 

*FIELDNAME=RFP  NO,  ALIAS=RFPN  ,  FO RM AT = I  6 , F I ELDT Y P E =  I  , 

FIELDNAME  =  RFP_DATE,  ALIAS=RFPD  ,  FO R M AT : I 6M D Y , 

FIELDNAME  =  DEP  ID,  ALIAS  =  DEPC,  FORMAT  =  A2 , 

FIELDNAME:RFP_SUBJECT ,  ALIAS=SUBJ,  F0RMAT=A50, 

FIELDNAME  =  N_OF_V  E N DO  R S  ,  ALIAS  =  NOV,  F0RMAT=I2, 

FIELDNAME=NOF_PRQPOSAL,  ALIAS=N0P,  FORMAT: I  2  , 

FIELDNAME: RFP_COMMENTS,  ALIAS:,  F0RMAT:A50  , 

FILENAME:POWRFC ,SUFFIX:FOC  (Request  For  Contracting) 

SEGNAME:ONE,SEGTYPE=S1 

*FIELDNAME:RFC  NO,  ALIAS  =  RFCN,  FO R M A T = I  6 , F I E L DT Y P E =  I  , 

F IELDN AME: RFC_DATE ,  ALIAS:RFCD,  FORMAT: I 6MDY , 

FIELDNAME:RFP  NOT,  ALIAS:RFPN  1  ,  FORMAT :I  6  , 

FIELDNAME:DEPART  NOT,  ALIAS:DEPN 1 ,  F0RMAT:A2 , 

FIELDNAME: RFC_SUBJ EOT ,  ALIAS: RFCS,  FORMAT  =  A50  , 

FIELD NAME:FUND_LETTER ,  ALIAS=FLN ,  FORMAT:AjO, 

F IELDN AME: FUN D_AMMOU NT ,  ALIAS:FAM0UNT,F0RMAT:D12.2M, 
FIELDNAME:RFC  COMMENT,  AL I  AS : R F C COM , FO R M AT : A 5 0  , 


FILENAMEsPQWVNDR , SUFFIX sFOC 


iVendor  File) 


SEGNAMEsONE, SEGTYPE=S1 


*FIELDNAME= VENDOR  ID, 

ALIASs VCODE , 

FORMAT=I4, 

FIELDN A  M  E  =  T  H  0  M  A  3_  V  0  L_  N , 

ALIASsTHVN , 

FORMATsI2 , 

FIELDNAME  s  THOM A3_P AG_N , 

ALIASsTHPN , 

FORMATsI 3 , 

FIELDNAMEs VENDOR_NAME , 

ALIASs VNAME , 

FORMAT s A50  , 

FIELDNAME=POF_CONTACT , 

ALIASsPQFC , 

FORMATsA25  , 

FIELDNAMEs VENDOR_AD RES , 

ALIASs VADRS , 

FORMAT s A25  , 

FIELDNAMEsVENDOR_CITY, 

ALIASs VCTY , 

FORMATsA  1  5  , 

FIELDNAMEs VEND0R_3TATE , 

ALIASs VSTA , 

FORMAT  s A4  , 

FIELDNAMEs VENDOR_ZIPC , 

ALIASsVZIPC, 

FORMATsI 7 , 

FI ELDNAMEsVENDOR_ PHONE, 

ALIASs VPH , 

FORMATsA  1  4  , 

FIELDNAMEs VENDOR_TELEX , 

ALIASsVTLX, 

FORMATsA  1  2  , 

FIELDN AM EsVEN DO R_ ASSET, 

ALI ASsVASS , 

FORMATS A6  , 

FIELD NAMEsVEN DO R_ST ART , 

ALIASsVSTD , 

FORMATS A4  , 

FIELDNAME=V_ ACTIVITIES , 

ALIASs VAC , 

FORMATS A50  , 

FIELDNAMEsDEP  CUSTOMER, 

ALIASsDEPC , 

FORMATS A2 , 

FILENAMEsPOWCONTR ,5UFFIX=F0C  (Contract  File) 

SEGNAMEsONE, SEGTYPEsSI 

*  F IELDNAMEsCONTRACT  NO,  ALIASsCN,  FORMAT s I  6 , F I ELDT Y P E = I 

FIELDNAM£sCONTRACT_NAM  ,  ALIASsCN AM  ,  FORMAT  =  A50  , 

FIELDNAMEs CO  NT  R  ACT_DES ,  ALIASsCDES,  F0RMAT  =  A50, 
FIELDNAMEsCONTRACT  PEP,  ALIAS=CDEP,  FORMAT=A2, 

FIELD NAMEsCONTRACT  VIP,  ALIASsCVID,  FORMATsI4, 
FIELDNAMEsCONTRACTDAT,  ALIAS  =  CDATE  ,  FORMAT  =  IoMDY, 


FIELDNAME=CONT_ VALUE ,  ALIAS 
F I E  L  D  N  A  M  E  s  C  C  N  T_  C  0  M  M ,  ALIAS 

FILENAMES  POWBANK , SUFFIX  =  FOC 
SEGNAM E=ONEfSE GTYPEsSl 
•FIELDNAMEsBANK  NO.  ALIAS 

FIELDNAMEsBAN K_N  AM  E ,  ALIAS 
FIELDN AMEsBANK_ADDRES ,  ALIAS 
F I E  L  D  N  AM  E  s  3  A  N  K_  C I T  Y ,  ALIAS 
FIELDNAMEsBAN  K_ST  ATE ,  ALIAS 
F I E  L  D  N  A  M  E  s  B  A  N  K_  Z I P  C ,  ALIAS 
FIELD NAMEs3ANK_ PHONE ,  ALIAS 
FIELDNAMEsBAN K_TE  LE  X ,  ALIAS 

FILENAMES POW I NVOI ,SUFFIX=FQC 
SEGNAMEsONE , SEGTYPEsS  1 
•FIELDNAMEsINVOICE  NO,  ALIAS 
FIELD NAMEsINV  CONI  NO,  ALIAS 

f:eldname=invoice_subj ,  ALIAS 

FIELD NAMEsINV_VENDR_ID ,  ALIAS 
FIELDNAMEsINVOICE_DATE ,  ALIAS 
FIELDNAMEs IN VOIGE_V ALU ,  ALIAS 
FIELDNAME=INV_DUE_DATE ,  ALIAS 
FIELDNAMEsINV  CHECK  NO.  ALIAS 
F I E  L  D  N  A  M  E  s I N  V_  P  A  Y_  D  A  T  E ,  ALIAS 
FIELDNAMEsINV  COMM,  ALIAS 


CVALUE,F0RMATsD14,2, 

CCOMM,  FCRMAT=A5G, 

(Bank  File) 

BNO,  F0RMATsI2 , FIELDTYPE 
BNAME,  FORMAT  s  A20  , 

BADRES , FORMATS A25  , 

BCTY ,  FQRMATsA25, 

BSTATE , FORMATS A4  , 

3ZIPC,  FORMATsI?, 

BPHONE , FORMATsA  1  4  , 

BTLX ,  FORMATsA  14, 

(Invoice  File) 

INVN,  FORMATsIb , FIELDTYPE 
INVCN,  FORMATsIS, 

INVSUBJ ,FORMAT  =  A50  , 
INVVID,F0RMAT=I4  , 

INVD,  FORMATs I 6MDY  , 

IVLU,  FORMATs  D 1 2 . 2M  , 

IDUE,  F0HMAT=I6MDY, 

ICHKNO ,F0RMATsI6  , 

IPD,  FORMATsIoMDY  , 

,  FORMAT=A50, 
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FILENAMES  POWORDER , SUFFIXsFOC 
SEGNAME=ONE, SEGTYPEsSI 
»FIELDNAME=PAY  order  no, alias 
F..ELDN  AMEsPAY_0RDR_DAT  ,  ALIAS 
FIELDNAMEs PAY  Q  INV  NO,  ALIAS 
FIELDNAMEs PAY  ORD  BANK,  ALIAS 
FIELDNAMEsPA  Y_0_ V  ALU  E ,  ALIAS 
FIELD NAM E=P AY  0  VIP,  ALIAS 
F I E  LD  N  AM  E  =  P  A  Y_TG  w  H  0  M ,  ALIAS 

FILENAMEsPOWICLAS , SUFFIXsFOC 
SEGNAMEsONE.SEGTYPEsSI 
•FIELDNAMEs VENDOR  IDT,  ALIAS 
FIELDNAMEs VNDR  ITEM  C,  ALIAS 


(.Pay  Order  File, 

PON,  FOR MATsIo, FIELD! YPEsI, 
POD,  FORMATsIoMDY  , 

PQINVN ,FORMATsI6  , 

POB,  F0RMATsI2, 

POV,  FORMATsD 1 2 . 2M  , 

POVID ,  FORMATsI 4 , 

POTO,  FORMAT  s A25  , 

(Items  Class  File; 

VID1,  FORM AT  =  I  4  , 

VIC,  FORMATsA15, 


FILENAMES PQWVDEP , SUFFIXsFOC  (Vendor  Department  File 

SEGNAMEsONE.SEGTYPEsSI 

•FIELDNAMEs VENDOR  ID2,  ALIAS=VCODE2,FORMAT=I4, 

FIELDNAMEs VNDR  PEP  NO,  ALIASs,  FORMATsA2 , 


FILEN AM EsPOWSHIPN, SUFFIXsFOC  (Snipment  Notice  File) 

SEGNAMEsONE.SEGTYPEsSI 

•FIELDNAMEsSHIP  NOTICE,  ALIAS  =  SHN,  FORM AT  =  I  6 , F I E LDT Y P E s  I  , 

FIELD NAMEsSHIP  CO  NT  NO,  ALIASsSHCN, 


1  2  1 


FORMATsI 4  , 


FIELDNAME=3HIP  SUBJECT,  ALIAS:SHS, 


FORMAT=A50 , 


FIELDNAME=SHIP  INV  NO,  ALIAS=5HIN,  FORMAT=I6,  ; 

FIELDNAME  =  SHIP_DATE  ,  ALIAS  =  SHD,  FC  R  M  A  T  =  I  6M  D  Y  ,  $ 

FILENAME=POWCITEM,SUFFIX=FOC  Contract  Item  File 

SEGNAME=ONE,SEGTYPE=S1 

*FIELDNAME=CQNTRACT  N01,ALIAS=CN1,  FCRMAT=I6,  $ 

FIELDNAMEsITEMD  CODE,  ALIAS=ICOD  FORMAT=A12  J 

FIELDNAMEsI TEM_DESC  R  P  ALIAS  =  IDESC  FORMAT: A jO  $ 

FIELDNAME  =  UN  IT -OF-ISSUE  ALIAS-UI  FORMAT: A 2  S 


FIELD N AM E:CONT_QTY  ALIAS=CI,  ■  FORMAT=AJO,  5 

FILENAME: POWBNK AC ,SUFFIX:FOC 

SEGNAME:ONE,SEGTYPE:S1 

«FIELDNAME: BANK  NUNBER,  ALIAS:BID1,  FO  R M  A T  :  I  2  ,  F  I  E  L DT  Y  P  E  :  I  ,  i 
F 1  £  LD  N  AM  E : B AN  K  ACCOUNT,  ALIAS:BACC,  FORMAT:A10,  i 

2.  Using  PC/FOCUS  for  the  POW  Softeware 

The  purpose  of  this  section  is  to  justify  the  use  of 
PC/FOCUS  as  a  DSS  generator  for  the  POW  system.  Some  of  tne 
most  important  and  useful  features  of  PC/FQCUo  are 
highlighted  below. 

a.  Files  Description 

PC/FOCUS  supports  a  hierarchical  model,  i.e.  the 
file  description  allows  a  one  to  many  relationship  between 
segments  (records)  in  FOCUS  file  or  the  parent  to  many  child 


segments.  The  data  description  language  of  PC/FOCUS  allows 
free  format  delimited  by  S  to  signify  the  end  of  single 


description.  A  checking  procedure  can  be  used  to  cnecK 
errors  in  the  file  description.  After  data  entry,  changes  in 
the  file  description  are  not  allowed  unless  they  are  a  part 
of  reorganization  of  the  physical  database.  (Rebuild 
facility  of  PC/FOCUS  allows  down  loading  an  "old"  physical 
data  base  to  a  "new"  description  carefully  made  by  the 
designer.  File  relationships  (cross-reference  of  files  )  in 
the  database  can  be  made  static  through  FOCUS  file 
description  as  a  parent  child  relation  or  dynamic  using 
PC/FOCUS  JOIN  command  which  can  be  invoked  when  needed  to 
link  two  entire  file  structures.  The  condition  for  using  the 
JOIN  command  is  to  allow  at  least  one  field  in  the  desired 
segment  of  each  file  to  be  of  type  "indexed"  in  the  file 
description.  Any  number  of  fields  may  be  indexed  on  a 
segment.  PC/FOCUS  FileTalk  also  allows  easy  checking  of  file 
descriptions  by  producing  a  graphical  representation  of 
files  and  segment  relations. 

b.  Data  Manipulation  in  PC/FOCUS 

A  non-procedural  language  is  used  for  data 
manipulation  and  producing  reports  from  the  database.  Two 
functional  types  of  manipulation  language  are  available  in 
PC/FOCUS:  the  transaction  processor  and  the  dialogue 
manager . 

( 1 )  The  Transaction  Processor .  is  used  for 
report  preparation  by  invoking  the  MODIFY  command  and  typing 
an  imperative  English  statement  consisting  of  one  or  more 


verbs  followed  by  verb  objects  and  optionally  by  various 
other  phrases.  All  these  statement  follow  the  general  rules 
of  English  grammar.  The  request  statement  contains  all 
information  the  user  has  to  provide  in  order  to  retrieve  the 
desired  records,  perform  any  calculations,  sort  lines, 
accumulate  totals,  etc.  Information  which  is  not  provided 
explicitly  by  user  will  be  supplied  by  FOCUS  as  default 
options.  The  transaction  processor  has  a  facility  to  create 
screens  for  fill-in-th e-blank  data  entry  called  FIXFORM.  The 
MATCH  subcommand  is  used  to  designate  fields  to  rnatcn. 
Logical  subcommands  are  used  to  process  any  demands  from  the 
database.  It  is  possible  to  store  FOCUS  transaction 
processing  routines  in  a  command  file  for  later  use. 

(2)  The  Dialogue  Manager.  is  a  stored 
procedure  that  may  contain  variable  information  for  whicn  a 
value  is  provided  only  at  the  time  of  execution.  The 
variables  can  be  used  to  represent  numeric  constants,  dates, 
or  to  conduct  a  dialogue  by  prompting  the  user  for  a 
response.  The  Dialogue  Manager  is  invoked  by  typing  the 
FOCUS  command  "EXEC"  or  "EX"  followed  by  the  name  of  the 
procedure  . 

c.  Built-in  Facilities  in  PC/FOCUS 

In  addition  to  file  description  and  data 
manipulation,  there  are  many  important  facilities  that  make 
using  PC/FOCUS  database  atractive  for  our  system.  The 


following  are  the  summary  of  each  facility  as  presented  in 


(1)  Describing  External  Files.  The  report 
request  language  can  be  used  on  data  files  that  are  not 
maintained  by  FOCUS  and,  hence,  are  external.  These  are 
existing  files  which  are  maintained  by,  or  extracted  from, 
other  systems. 

(2)  Maintaining  FOCUS  database.  A  simple 
language  is  used  to  control  all  the  processes  of  adding  new 
records  to  FOCUS  database,  deleting  records, and  changing 
values  in  existing  records.  Coupled  with  a  transaction 
validation,  computational,  and  logging  facilities,  the 
result  is  surprisingly  brief  set  of  ideas  that  must  be 
learned  in  order  to  maintain  FOCUS  database. 

(3)  SCAN  -  Interactive  Editing  Facility.  The 
SCAN  facility  is  designed  to  take  advantage  of  an  inter¬ 
active  environment.  It  allows  a  user  to  'browse*  through  a 
FOCUS  file  of  any  size  by  issuing  one-line  commands  such  as 
TYPE,  NEXT,  REPLACE,  ETC.  and  receive  an  immediate  response 
oefore  issuing  the  next  command.  Users  familiar  with  a  text 
editor  will  find  the  similarities  useful  in  learning  SCAN. 

( 4 )  ANALYSIS  -  Formal  Statistical  Analysis, 
normal  statistical  techniques  such  as  multiple  regression, 
step-wise  regression,  and  correlation  analysis  are  performed 
on  data  in  FOCUS  (or  external)  files.  Control  over  the 
techniques  is  exercised  in  an  interactive  dialogue.  The 


displays  include  all  of  the  formal  statistical  quantities. 


(5)  GRAPHS .  The  report  request  language  is 
used  to  phrase  and  control  graphical  displays  such  as  point 
plots,  bar  charts,  histograms  and  scatter  diagrams.  .‘Jormai 
terminal  output  or  nigh  resolution  graphics  can  be  prepared. 
Default  values  are  used  for  widths,  grid  values,  etc.  to 
simplify  the  process,  but  user  can  specify  precise  values 
when  customized  plots  are  needed. 

(6)  User  Defined  Language.  Users  can  change 
the  language  and  vocabulary  of  FOCUS  to  suit  their  own  needs 
and  preferences. 

(7)  Financial  Modeling  Language.  The  report 
request  language  has  a  series  of  features  designed 
specifically  for  the  preparation  of  'row  oriented'  reports. 
These  arise  frequently  in  financial  applications  where 
reports  such  as  Balance  Sheets  and  Cash  Flow  statements  are 
needed  . 

( 8  )  FIDEL-FOCUS  Interactive  Data  Entry  Language 
FIDEL  enables  the  design  and  implementation  of  full  screen 
interactive  data  entry  systems  as  part  of  tne  data 
maintenance  facility.  It  also  provides  easy  development  of 
'menu'  selection  processes. 

3 .  Database  Creation 
a .  Data  Entry 

The  Automode  utility  is  used  to  enter  data  in 
the  database.  Test  data  have  been  generated  to  load  the 
database.  Real  data  will  be  loaded  during  the  imp  1  emen t a t  i  o n 


phase  . 


b.  Validation 

PC/FOCUS  allows  validation  of  data  during  3  a  t  a 
entry.  A  record  is  rejected  if  any  violation  of  field  format 
occurs  or  if  a  record  with  the  same  key  field  is  entered 
twice.  In  the  latter  case  the  last  one  entered  will  be 
rejected  by  PC/FOCUS.  Automode  does  not  allow  range 
validation.  There  is  a  very  powerful  tool  for  interactive 
data  entry,  FOCUS  INTERACTIVE  DATA  ENTRY  LANGUAGE  (FIDEL)) 
FIDEL  allows  the  user  to  enter  data  through  a  visual  'fill 
in  the  form'  method.  After  each  successful  transaction,  one 
data  portions  of  the  screen  are  blanked  out,  leaving  only 
the  mask.  If  an  error  is  discovered  in  the  transaction  an 
error  message  will  appear  on  the  bottom  of  the  screen.  A 
bell  will  ring  (if  the  CRT  is  so  equipped)  and  the  screen 
will  not  blanked  out,  thus  giving  the  operator  a  chance  to 
correct  the  error  and  retransmit  the  screen.  The  FIDEL 
provides  validation  and  protection  mechanisms  during 
interactive  data  entry.  The  complete  language  rules  and 
facilities  are  presented  in  the  PC/FOCUS  user  manual  [Ref. 
3 J .  In  this  thesis  we  are  not  going  to  use  this  tool 

because  of  the  time  limitation  for  the  thesis.  Auto mode 
provides  adequate  facility  for  data  entry  in  this  prototype. 

c.  Security 

One  problem  with  using  the  computer  is  the 
possibility  of  losing  data.  An  important  step  in  developing 


any  computer  system  is  instituting  procedures  for  backup  of 
the  actual  data  in  the  database  and  for  prevention  of 
unauthorized  access  to  data.  In  our  system,  the  security 
procedure  is  simple.  FOCUS  files  containing  data  nave  an 
extension  xxx.FOC  to  distinguish  them  from  other  files.  The 
prefix,  POW  is  used  to  precede  all  files  generated  by  the 
system.  Only  an  authorized  person  is  allowed  to  delete  these 
files.  Every  week  a  backup  for  all  files  in  the  database  is 
done  on  floppy  diskettes.  Data  entry  and  updating  is 
limited  to  authorized  persons  only.  PC/FOCUS  has  powerful 
tools  for  security  which  can  be  used  for  later  development 
of  the  system. 

d.  Database  Size 

The  following  table  shows  the  length  of  the 
different  database  files: 


FILE  NAME 

LENGTH 

ORGANIZATION 

NO  OF  RECORDS 

POWDEP 

27 

Indexed 

20 

PQWVNDR 

2  2  j 

Indexed 

500 

POWICLAS 

34 

200 

POWVDEP 

6 

1000 

POWRFP 

1  1  8 

Indexed 

800 

PQWRFC 

1  62 

Indexed 

150 

PQWCQNTR 

182 

Indexed 

600 

POWC ITEM 

36 

3000 

POWIN V 

154 

Indexed 

2000 

POWORDR 

63 

Indexed 

700 

POWCHECK 

6  j 

Indexed 

1  bOO 

POWBANK 

1  1  1 

Indexed 

20 

POWBNKAC 

1  2 

40 

POWSHIPN 

72 

Indexed 

2000 

TOTAL 


1  26  j 


125  -SO 


The  database  can  be  used  for  ail  the  POWCP  Dy  using 
the  Tabletalk  utility. 

a.  RFP  process 

(1)  Routine  //  1.  The  routine  is  generated  to  match 
the  data  classes  of  any  particular  RFP  with  the  data  classes 
of  all  vendors.  The  result  is  a  vendor  list  for  all  vendors 
that  matches  the  data  classes  of  the  RFP. 

(2)  Routine  If  2.  This  routine  generates  an 
RF P/ P ro posa 1 s  list  which  summarize  the  RFP  process  and  shows 
all  proposals  received  from  all  vendors.  This  list  is  send 
along  with  the  physical  proposals  to  AA. 

(3)  Routine  tf  3.  This  is  a  general  purpose  routine 
which  produces  a  list  of  the  basic  data  in  each  database 
file.  This  routine  can  be  enhanced  to  produce  a  variety  of 
lists  which  suit  certain  logical  conditions  such  as  a  list 
of  all  vendors  with  specific  data  classes.  Of  course  we  have 
to  join  the  vendor  data  class  file  with  the  vendor  file 
before  we  can  generate  the  reports. 

b.  Administer  Open  Contacts  Function 

( 4 )  Routine  ff  4 .  Produce  a  list  of  all  invoices 
paid  to  a  particular  contract  with  its  values  and  paid 
dates.  The  join  between  the  contract  file  and  the  invoices 
file  must  be  done  before  we  use  the  Tabletalk.  The  same 
routine  is  generated  by  the  Tabletalk.  Similar  routines  can 
be  generated  for  the  pay  order  and  the  shipment  notice. 


(5)  Routine  tf  5.  Produce  a  list  of  all  checks  paid 
to  a  particular  vendor.  Joins  w - 1 h  the  vendor  file  and  Che 
checks  file  are  necessary  before  producing  the  report. 

( 6 )  Routine  it  6 .  Produce  a  Payment  Plan  for  all 
invoices  received  and  validated  to  be  paid  on  a  schedule 
according  to  the  due  dates  of  each  invoice.  This  list  allows 
the  financial  officer  to  manage  the  payment  in  the  most 
effective  way  and  prevent  missing  payment  of  any  invoice. 

( 7 )  Routine  />  7 .  Produce  the  financial  scat  us 
about  all  active  contracts  which  shows  the  contracts  against 
the  amount  of  money  paid  for  each  one.  This  report  is  very 
important  for  the  cash  flow  management  of  the  fund  dedicated 
for  the  contracts. 

(8)  Routine  t  8 .  A  validation  list  of  all  check 
values  and  dates  issued  to  a  particular  bank.  This  list  can 
be  used  to  check  the  balance  sheet  of  the  bank.  This  routine 
can  be  adapted  to  produce  reports  to  monitor  payment  from 
loans  . 

( 9 )  Routine  If  9 .  Produce  a  status  list  of  a  a  c  n 
contract  from  the  point  of  view  of  the  shipment  and  compare 
these  reports  with  the  contract  terms.  The  importance  of 
this  report  comes  from  its  ability  to  measure  vendor 
performance  and  address  any  delay  from  the  scnedale  to 
allow  the  contracting  officer  to  take  the  necessary  action 
in  suitable  time. 


* 


(  10) 

Routine 

it 

10. 

Produce 

a  1 i s  o  of  tne 

recei v e  d 

sni pment 

notices 

to 

compare  it 

with  the  reports 

received 

from  the 

Freight  Forwarder 

to  check  the  performance 

of  FF. 

(11) 

Routine 

it 

1  1  . 

Produce 

list  of  officers  under 

training 

for  each 

contr 

acts  with  information  about  the 

training 

period. 

(12) 

Routine 

it 

12. 

Produce 

mailing  list  each 

month  to 

send  the 

monthly 

salary 

.  This 

list  takes  much  time  in  the 

manual  system . 

(13) 

Routine 

it 

13. 

Produce 

a  list  of  training 

schedule 

dates  to 

inform 

AA 

ahead  of 

time  to  prepare 

and  send 

training 

officers. 

(  14  ) 

Routine 

it 

14. 

A  list 

is  produced  of 

all  the 

Guarantee  letters  whose  validity  date  is  close  to  the  end  of 
the  validity  period,  sorted  by  date  so  the  renewal  can  be 
done  in  a  suitable  amount  of  time.  This  list  is  produced  as 
required  to  assist  the  Financial  officer  in  following  the 
guarantee  letters. 

5 .  Designed  Software 

The  P 0 W  software  is  designed  as  a  menu  driven  by  the 
user.  The  P 0 W  main  menu  screen  is  appear  when  issue  the  name 
of  the  main  module  (EX  PO WM A I N M . F E X )  .  Selecting  the  options 
from  the  screen,  each  menu  leads  the  user  to  another  one.  A 
help  facility  is  provided  to  let  users  move  from  one  screen 
to  another.  Three  utilities  we  are  going  to  use  are  tne 
Filetalk  which  allow  describing  the  Master  Data  File  , M D F ;  , 
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m*; 


T*T 
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the  Aulomode  which  allow  loading  the  database,  and  tne 
Taoletalk  which  allow  producing  different  reports.  Describ¬ 
ing  MDF  is  already  done  by  the  author  after  determining,  the 
software  requirements  of  P 0 W C P ,  a  meaningful  names  is  select¬ 
ed  to  allow  easy  understanding  for  the  user.  The  following 
pages  illustrate  a  navigation  through  the  designed  system: 
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Select  Option  1 


WELCOME  TO  THE  PC/FOCUS 
AUTOMATIC  DATA  MANAGEMENT  SYSTEM 


PLEASE  ENTER  THE  NAME  OF  THE  FILE 
YOU  DESIRE  TO  MODIFY: 


File  name  — > 


POWDEP 


Screen  //  2, Main  Edit 


AUTOMATIC  DA'TA  MANAGEMENT  FILE  POWDEP 
PLEASE  SELECT  A  PROCESS 

1  ADD  NEW  RECORDS 

2  ADD  NEW  RECORDS,  UPDATE  EXISTING  RECORDS 

3  UPDATE  EXISTING  RECORDS  ONLY 

4  DELETE  RECORDS 

5  RETURN  TO  MAIN  MENU 


ENTER  YOUR  SELECTION  (1  2  3  4) 


Select  Option  1 


AUTOMOD  OPTION  in.  ..ADD  NEW  RECORDS 


'TAB'  FOR  NEXT  FIELD 
' F7 '  FOR  PRIOR  SCREEN 


'ENTER'  TO  TRANSMIT  DATA 
'  F<J  '  FOR  NEXT  SCREEN 


' F  3 '  TO  RETURN  TO  PREVIOUS  MENU 


DEPART  ID  :  02 

DEPART  NAME:  ARMAMENT  AUTHORITY 

Response  — >...  RECORD  ACCEPTED  .  ENTER  NEXT  RECORD  .... 

Enter  the  same  data  to  check  validation  facility 
DEPART  ID  :  02 

DEPART  NAME:  ARMAMENT  AUTHORITY 


Response  — >...  RECORD  ALREADY  EXISTS  .  REJECTED 


Select  option  2  in  Edit  Screen 


AUTOMCD  OPTION  it  2  .  .  .ADD/UPDATE  RECORDS 


'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  D  A  T  A 

’  F7  '  FOR  PRIOR  SCREEN  ' F3 '  FOR  NEXT  SCREEN 

'  F j  '  TO  RETURN  TO  PREVIOUS  MENU 


DEPART  ID  : 


DEPART  NAME: 


Enter  key  (02) 


DEPRESS  ENTER 


DEPART  ID  :  02 

-  DEPRESS  ENTER 

DEPART  NAME:  ARMAMENT  AUTHORITY 


F  0  C  J  5  response  -->  UPDATING  EXISTING  RECORD 


Enter  new  Department  (03) 


DEPART  ID  :  Qj 


DEPART  NAME:  TANK 


DEPRESS  ENTER 


Acknowledge  —  > 


ADDING  NEW  RECORD 


Select  option  3  in  Edit  Screen 


AUT 

M  0  D  u  P  i  a  v  i  J 

■t  j>  .  .-.UPDATE 

EXISTING  RED 

'  T  A  3  ' 

FOR 

NEXT 

F  I  E  L  D 

'ENT 

E  R  ’  TO  TRANS 

1  C* » 

.  ( 

FOR 

PRIOR 

SCREEN 

'  F  3  ' 

FOR  NEXT 

'  F 3  '  T 3  RETURN  TO  PREVIOUS  MENU 
DEPART  ID  :  03 

-  DEPRESS  ENTER 

DEPART  NAME:  TANK 

-  ENTER  NEW  VALUES 


Enter  new  record 


DEPART  ID  :  04 

-  DEPRESS  ENTER  - 

DEPART  NAME: 

Acknowledge  — >  RECORD  DOES  NOT  EXIST ....  ENTER  NEXT  RECORD 


Select  Option  3  in  Edit  Screen 


AUTOMOD  OPTION  #4.  ..DELETE  EXISTING  RECORDS 


'  T  A3 '  FOR  NEXT  FIELD  ’ENTER’  TO  TRANSMIT  DATA 

' F 7 '  FOR  PRIOR  SCREEN  ’  F8 '  FOR  NEXT  SCREEN 

' F  3 ’  TO  RETURN  TO  PREVIOUS  MENU 


RT  ID  :  03 


Screen  It  3.  Vendor  Data 


VENDOR  ID 


THOMAS-VOL-N : 
VENDOR  NAME: 
POP  CONTACT: 
VENDOR  ADRES: 
VENDOR  CITY: 
VENDOR  ZIPC: 
VENDOR  TELEX: 
VENDOR  START: 


Screen  If  4,  Item  class 


VENDOR  I D 1  : 

VNDR  ITEM  C: 

-  DEPRESS  ENTER 


Screen  If  5,  Vendor  /  Department 


VENDOR  ID2  : 
VNDR  DEP  NO: 


Screen  //  6,RFP  Data 


DEPRESS  ENTER  - 

DEP  ID  : 

NOF  PROPOSAL: 


RFP  NO 


RFP  DATE  : 
RFP  SUBJECT: 

N  OF  VENDORS: 
RFP  COMMENTS: 


DEPRESS  ENTER  - 

THOMAS  PAG  N: 


VENDOR  STATE: 
VENDOR  PHONE: 
VENDOR  ASSET: 


Screen  #  7,  RFC  Data 


RFC  NO  : 

-  DEPRESS  ENTER  - 

RFC  D  ATE  :  RFP  NOI 

DEPART  NO!  : 

RFC  SUBJECT: 

FUND  LETTER: 

FUND  AMMOUNT: 

R  [■  C  COMMENT: 


Screen  tf  8, Contract  Data 


CONTRACT  NO: 


DEPRESS  ENTER 


CONTRACT  NAM 
CONTRACT  DE5 
CONTRACT  DEP 
CONTRACT  DAT 
CONT  COMM  : 


CONTRACT  VID 
CONT  VALUE  : 


Screen  #  9, Contract  Item 


INVOICE  NO  : 


DEPRESS  ENTER 


INV  CONT  NO: 
INVOICE  SUBJ: 
INV'  V  E  N  D  R  ID: 
INVOICE  VALU: 
INV  CHECK  NO: 
INV  COMM  : 


INVOICE  DATE 
INV  DUE  DATE 
INV  PAY  DATE 


PAY  ORDER  NO 


DEPRESS  ENTER 


PAY  ORDR  DAT: 
PAY  ORD  BANK: 
PAY  0  VID  : 
PAY  TO  WHOM  : 


Screen  #  12 


PAY  0  INV  NO 
PAY  0  VALUE: 


CHECK  NO  : 

..  _ _  nFPRF^^  fmtfr  _ 

CHK  PAY  DATE: 

CHK 

INV  NO 

CHK  BANK  : 

CHK 

VALUE 

CHK  VENDR  ID: 

CHK  TO  WHOME: 

Screen  It  13>  Bank  Data 


3ANK  NO 


BANK  NAME 
BANK  ADORES 
BANK  CITY 
BANK  STATE 
BANK  PHONE 


DEPRESS  ENTER 


BANK  ZIPC  : 
BANK  TELEX  : 


Screen  It  14,  Bank  Account 


BANK  N0 1  : 

BANK  ACC  NO: 

- - -  DEPRESS  ENTER 


Screen  It  15,  Shipment  Notice 


SHIP  NOTICE: 


SHIP  CONT  NO: 
SHIP  SUBJECT: 
3H  I.P  I N  V  NO: 


DEPRESS  ENTER  - 

SHIP  DATE 


VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS: 

1.  The  POW  system  as  presented  in  this  thesis  is  not 
exactly  the  same  as  the  existing  POW  system  because  of  time 
and  travel  constraints,  however,  the  main  functions, 
problems  and  opportunities  of  POW  have  been  addressed. 
Adaptation  of  the  system  to  POW  or  any  other  Procurement 
Office  will  need  only  minor  effort  compared  to  the  effort 
spent  in  developing  this  system.  Fortunately  PC/FOCUS  with 
its  Fourth  Generation  Language  and  facilities  will  allow 
easy  adaptation  of  the  system. 

2.  No  system,  no  matter  how  efficient  it  is,  will  be 
effective  if  it  is  not  employed  by  its  users.  There  is  the 
possibility  that  the  proposed  system  will  not  be  used  any 
more  effectively  than  the  present  manual  system.  However,  it 
is  felt  that  the  probability  of  this  happening  will  decrease 
as  the  users  realize  the  benefits  of  the  system.  During  the 
analysis  phase  all  users  of  the  system  showed  willingness  to 
participate  in  using  a  computer  system  which  would  improve 
the  effectiveness  of  the  system.  The  manual  system  has  no 
more  capability  to  deal  with  the  increased  demand  for 
procurement  activities  in  the  USA  market.  Of  course,  it  is 
the  responsibility  of  POW  to  support  and  require  use  of  the 
system  once  it  has  been  proven  effective. 


0  .  Ine  approach  used  to  design  the  system  is  tne 
Iterative  Design  Approach  or  Staged  Development  Approach. 
The  present  design  of  POWCP  system  is  the  first  iteration, 
the  Commercial  Procurement  function.  After  receiving  user 
feedback  from  the  initial  system,  the  second  iteration  will 
start.  This  system  will  be  expanded  into  a  general  purpose 
Decision  Support  Systems  (DSS)  to  be  used  in  the  procurement 
activities  of  foreign  country  procurement  offices.  Such  a 
system  with  the  DSS  generator  'database'  will  provide  an 
excellent  decisionmaking  tool  as  well  as  providing  support 
for  routine  operation  of  the  Management  Information  System, 
for  example  financial  management  and  tracking  of  contracts. 

4.  Implementing  the  system  required  extensive  efforts  , 
especially  in  building  the  database  which  is  the  foundation 
for  any  other  improvements  to  the  system.  The  most  difficult 
problem  to  overcome  is  the  data  entry  phase  for  initial 
loading  of  the  database.  The  willingness  and  support  of  the 
POW  Director  and  specialized  officers  are  essential  for  the 
success  of  this  system. 


5.  The  use  of  PC/F0CU5  provides  fully  compatibilty 
with  the  mainframe  FOCUS  and  its  capability  to  handle 
external  files  (not  produced  by  FOCUS)  will  give  the  system 


flexibility  to  interface  with  other  systems. 

6.  As  long  as  increases  in  microcomputer  technology 
continue,  no  limits  are  foreseen  for  the  system  capability. 


including  multi-user  and  wide  area  communication  with  Cairo. 
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RECOMMENDATIONS: 


The  objectives  of  tne  thesis  nave  oeen  success fu-iy 
completed.  Learning  about  computer  systems  development 
methodology  without  application  is  like  taking  swimming 
lessons  without  actually  swimming.  The  process  of  developing 
POW  was  a  real  challenge.  The  following  remarks  about  the 
system  can  be  made: 

1.  At  the  beginning,  the  actual  size  of  the  system 
effort  was  underestimated  which  is  a  common  a  pitfall  in 
system  development. 

■  2.  Walking  through  the  details  of  the  system  using  the 
structured  systems  analysis  technique  enforced  the  developer 
to  address  and  describe  more  details  about  the  system  which 
spent  more  time  and  efforts  than  required  within  the  time 
limitation  of  doing  the  thesis.  However  this  technique  has 
been  proven  succeeded  in  designing  a  roubist  information 
systems  in  the  real  world  situation. 

3.  Combining  building  the  DSS  generator  with  the 
iterative  design  approach  of  DSS  leads  to  a  conflict  in 
developing  system  requirements.  The  DSS  generator  needs  a 
detailed  and  complete  systems  analysis  to  build  the  data 
dictionary  down  to  the  primitive  level  of  detail.  (Data 
elements  that  cannot  be  divided  any  more  and  processes  that 
cannot  be  exploded  any  more.)  On  the  other  hand,  the 
iterative  design  approach  requires  building  DSS  with  short, 
rapid  feedback  from  users  to  ensure  that  development  is 
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proceeding  correctly.  This  may  be  very  difficult  if  we  start 
from  a  manual  system  like  P 0 W .  To  solve  this  conflict  in  the 
real  world  probelms,  developing  the  DSS  (either  tne 
iterative  or  the  complete  DSS)  should  be  started  from  a 
database  foundation. 

4.  Using  software  development  tools  is  very  important, 
especially  in  building  the  DFD  and  the  system  data 
dictionary. 

5.  Importance  of  documentation  is  addressed  during  the 
systems  development.  Self  documentation  and  giving  data 
elements  meaningful  names  are  very  important  in  designing 
the  system. 


6. 

Deep 

understand ing 

of 

the  system  is 

hard 

to  obtain 

unless 

you 

walk  through 

the 

system.  The 

DFD 

gives  the 

developer  the  opportunity  for  self  feedback  and  to  readjust 
the  system  as  necessary. 

7.  This  thesis  can  be  used  as  a  requirements  document 
for  any  future  development  of  a  DSS  for  the  Egyptian  Armed 
Forces  . 

Based  on  the  learning  experience  dicussed  above,  the 
following  recommendations  can  be  made  for  the  future 
enhancements  of  the  POW  system: 

1.  It  is  strongly  recommended  that  efforts  continue 
on  designing  a  usable  DSS  for  POW.  The  co s t - b e n e f  i  t s 
of  using  the  system  is  extremely  favorable. 

2.  Utilization  of  PC/FOCUS  and  its  utilities  associated 
with  the  structured  system  analysis  technique  are 
most  suitable  for  the  iterative  design  approach  we 
used.  The  recommendation  is  to  purchase  the  software 
for  implementing  and  using  the  system. 

142 


j.  The  most  suitable  hardware  for  implementing  the 

system  are: 

a.  I3M-XT  or  I3M-AT  microcomputer  (IBM-AT  is 
preferable  because  its  faster  than  IBM-XT)  with 
640  KB  and  at  least  one  floppy  diskette  derive 

b.  Hard  Disk 

c.  IBM  Enhanced  Graphic  Adapter  to  allow  using 
,  Arabic  Language  facilities  in  PC/FOCUS. 

d.  Color  Monitor 

e .  Matrix  Printer 

f.  Power  Supply  and  Accessories 
4 .  Future  Recommendation 

It  is  recommended  to  advance  the  imole mentation  of 
the  proposed  system  until  the  third  iteration,  at  least.  The 
first  and  second  iterations  will  emphasize  building  the  DSS 
generator  and  giving  acceptance  by  POW  users.  The  third 
iteration  will  use  the  PC/FOCUS  capability  to  build  other 
two  modules  of  the  DSS:  a  model  management  subsystem  which 
allows  analytic  capabilities  to  be  added  to  the  system  like 
evaluation  of  alternatives  and  formulating  relationships 
between  variables  in  a  way  that  permits  the  creation  of 


simulation 

or 

"  w  h  a  t 

if" 

models, 

and 

a  dialog  management 

component 

which 

can 

be 

tailored 

to 

POW  functions  with  a 

complete 

help 

facility 

to  give 

users 

of  the  system  full 

capabilities  without  prior  knowledge  in  computer 
programming.  PC/FOCUS  has  the  facilities  to  build  both 


componen  ts . 


APPENDIX  A 


DFD  CONVENTIONS 

Structured  Systems  Analysis  (SSA),  as  presented  in  the 
reference  "  Structured  Systems  Tools  and  Techniques "  by  G a n e 
and  Sarson  [Ref.  j]  is  a  technique  used  to  perform  systems 
specification.  Data  Flow  Diagrams  (DFD)  are  used  to  picture 
the  system  and  the  Data  Dictionary  is  used  to  define  the 
data  elements  and  the  data  structure.  Processing  logic  pres¬ 
entations,  such  as  decision  tables  and  structured  English 
are  used  to  precisely  specify  processing  sequences  in  terms 
that  are  understandable  to  the  user  and  developer.  For  ;he 
commercial  procurement  subsystem,  the  SSA  specification  is 
refined  to  the  detailed  design  level.  For  the  other  sub¬ 
system  we  stop  at  the  software  requirement  specification. 

A.  DFD  SYMBOL  CONVENTIONS 

The  logical  Data  Flow  Diagrams  are  very  important  for 
picturing  the  system  to  the  user;  they  provide  a  blue  print 
of  the  system.  This  way  of  presenting  the  system  provides  a 
communication  tool  between  the  systems  analyst  and  the  user 
on  one  side,  and  between  the  systems  analyst  and  the  soft¬ 
ware  programmers  on  the  other  side.  The  DFD  is  designed  to 
present  the  processes  in  a  logical,  top  down  approach, 


independent  of  physical  Location  or  physical  implementation. 


program,  via  satellite  datalink  or  anyplace  where  aata  flow 
from  one  entity  or  process  to  anther.  a  process  may 
physically  be  a  room  full  of  operators  receiving  mail 
orders,  getting  money  from  an  ATM  machine,  or  a  combination 
of  manual  and  automated  activities.  A  data  store  can  be  a 
rotary  card  file,  a  record  book,  a  microfiche,  a  filing 
cabinet,  even  a  table  in  core,  or  magnetic  file  on  tape  or 
disk.  Using  the  four  symbols  enable  us  to  draw  a  picture  of 
system  without  committing  ourselves  to  how  it  will  be 
implemented.  We  started  with  a  very  general  DFD  and  then  we 
could  go  to  the  details  step  by  step.  Figure  2.2  shows  the 
expansion  of  the  previous  DFD.  [Ref.  3} 


Figure  2  Expanded  Logical  DFD 


We  continue  the  expansion  of  DFD  in  a  top  down  fashion 
until  we  get  to  the  elementary  process  level,  that  can't  be 
divided  any  more. 

Tracing  the  DFD  is  very  important  to  understanding  the 
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system.  It  is  advisable  for  the  systems  analyst  to  present  a 
waU  through  of  the  DFD  with  users  at  the  beginning,  so  the 
user  can  get  the  concept  of  DFD.  The  preferable  way  to 


1  4  fc 


i  A  i  aft  ^ 


walkthrough  the  DFD  is  to  start  from  the  external  entities 
and  describe  the  input  data  flow  lines  and  each  process  in  a 
logical  sequence,  and  then  follow  the  output  data  flow  lines 
until  exits  or  is  stored  somewhere  in  the  DFD. 

B.  SYMBOLS  DESCRIPTION 

1 .  External  entities 

The  most  usually  logical  classes  of  things  or 
people  which  represent  a  source  or  destination  of 
transactions ,  e  .  g  ,  vendors,  officers,  tactical  units, 
Armament  Authority,  or  Department.  If  our  system  accepts 
data  from  another  system  or  provides  data  to  it,  that  other 
system  is  an  an  external  entity. 


Double 
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l 

External  Entity 


Figure  j  External  Entity 

An  entity  is  identified  by  lower  case  letters  in  the  upper 


left  nand  corner  for  reference. 
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Figure  4  Data  flow  symbols 


j .  Process 

The  process  can  be  symbolized  by  an  upright 
rectangle,  with  the  corner  rounded,  optionally  divided  into 
three  areas,  Figure  2.5. 
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Figure  o  Process 
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4. 


Data  store 


Data  store  can  be  symbolized  by  a  pair  of  hori 
parallel  lines,  closed  at  one  end  (Figure  2.6).  Each 
can  be  identified  by  a  " D "  and  an  arbitrary  number 
box  at  the  left  end  for  easy  reference. 


zon  t  a  i 

store 
n  i  n  a 


Open  ended  rectangle 


Figure  o  Data  store 

The  external  entities  and  the  data  stores  may  be 
duplicated  to  prevent  interconnections  between  data  flow 
lines  (Figure  2.7).  In  the  external  entity,  multiple  diag¬ 
onal  lines  are  used  to  indicate  that  the  external  entity  is 
pictured  more  than  once  in  the  same  DFD. 

Occurs  one  time 

- p. 


Occurs  tvo 
times 


Occurs  three 
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times 
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Figure  7,  Duplication  of  the  External  entity 


In  the  data  store,  multiple  vertical  lines  are  used 
to  indicate  that  the  data  store  is  pictured  more  than  once 


in  the  same  DFD,  Figure  2.8. 


Occurs  one  time 


Occures  tvo  times 


Occurs  three  times 


Figure  8,  Duplication  of  Data  Store 


The  information  presented  , so  far  is  sufficient  tc 
understand  the  DFD.  The  second  step  is  to  put  oetailed 
information  about  the  DFD  in  a  Data  Dictionary. 


C.  THE  DATA  DICTIONARY 

The  data  dictionary  keeps  all  the  details  and  contents 
about  the  data  flows,  data  stores,  and  processes.  The 
information  we  need  to  keep  in  the  data  dictionary  is 
classified  into  three  levels: 


Data  Elements 


1  . 

These  are  the  pieces  of  data  that  it  is  not  meaning¬ 
ful  to  decompose  further  for  the  applicated  at  hand;  e.g, 
date,  product  number,  etc. 

2 .  Data  Structures 

These  are  made  up  of  data  elements,  or  of  other  data 
structure,  or  a  mixture  of  both,  for  example: 

VENDOR 

VENDOR -ID 
VENDOR-NAME 
FIRST-NAME 
LAST-NAME 
PHONE 

AREA-CODE 

NUMBER 

EXTENSION 

BUSINESS-START-DATE 
BUSIN  ESS-ASSET-VALUE 
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APPENDIX  B 
MODULES  LISTINGS 


A.  POWMAINM : 

SET  PAUSE  =  OFF 
SET  MSG=ON 
-TOP 

LET  ! 1 =HELP 

-CRTCLEAR 

-BEGIN 

-SET  &REPLAY  =  0 ; 

-TYPE 

-CRTFORM 

-"  WELCOME  TO 

-"  POW  DECISION  SUPPORT  SYSTEM 

-"  MAINMENU 

-"  DATA  ENTRY  /  UPDATE  /  DELETE  _  1 


-"  CREATE  NEW  FILE  DESCRIPTION  .  2 

GENERATE  REPORTS  .  j 

-"  EXIT  .  4 

-"  HELP  .  5 


SELECT  (1  2  3  4  5)  <&REPLAY  <77 


-IF  &REPLAY 

EQ  1  GOTO 

AUTO 

ELSE 

IF 

&REPLAY 

EQ 

2 

GOTO 

FTALK 

ELSE 

IF 

&REPLAY 

EQ 

3 

GOTO 

TTALK 

ELSE 

IF 

&REPLAY 

EQ 

4 

GOTO 

EXIT 

ELSE 

IF 

4REPLAY 

EQ 

5 

GOTO 

HELP  ELSE  GOTO  NOPE 

-AUTO 

EX  POWAUTO 
-RUN 

-CRTCLEAR 
-GOTO  BEGIN 
-FT  A  LK 
FILE  TALK 


-CRTCLEAR 
-GOTO  BEGIN 
-TTALK 
TABLE  TALK 
-RUN 

-CRTCLEAR 
-GOTO  BEGIN 
-HELP 

EX  POWHELP 
-RUN 


-CRTCLEAR 
-GOTO  BEGIN 
-NOPE 

-TYPE  4REPLAY  IS  NOT  A  VALID  OPTION 

-...  PLEASE  REVIEW  OPTIONS  AND  RE-ENTER 

-GOTO  BEGIN 

-quit 

-EXIT 


B.  POWAUTO: 


-[Ref.  9] 


SET  PAUSE=OFF 
SET  MSG=OFF 
-TOP 

-CRTCLEAR 

-IF  41. EXIST  EQ  0  GOTO  NONAME; 
-SET  4FNAMEs41; 

-GOTO  GOTNAME 
-NONAME 

-SET  4 F N AM E  =  '  '  ; 

-START 

-CRTFORM 


_  »» 


WELCOME  TO  THE  PC/FOCUS 
AUTOMATIC  DATA  MANAGEMENT  SYSTEM 


PLEASE  ENTER  THE  NAME  OF  THE  FILE 
YOU  DESIRE  TO  MODIFY: 
CT.&FNAME  <77  " 


•TYPE 

•TYPE 

■TYPE 


PLEASE  WAIT 

THE  MAIN  MENU  IS  NOW  LOADING 
154 


-GOTNAME 

-IF  4FNAME . LENGTH  GT  3  GOTO  8ADNAME; 
-SET  4FF  =  4F NAME  11  '.MAS*  ; 

-DOS  STATE  4 FF 

-IF  4  RETCODE  NE  0  GOTO 

NONAME ; 

-SET  4REPLY=  '  '  ; 

-SECTION  1 


-CRTFORM 

_  ti 


_  ii 


_  it 
__  M 


AUTOMATIC  DATA  MANAGEMENT  FILE  <D . 4FNAME  <77 
PLEASE  SELECT  A  PROCESS 


_  it 


_  ii 


_  ii 


1 

2 

3 

4 


ADD  NEW  RECORDS 

ADD  NEW  RECORDS,  UPDATE  EXISTING  RECORDS 
UPDATE  EXISTING  RECORDS  ONLY 
DELETE  RECORDS 


_  ii 


RETURN  TO  MAIN  MENU 


.  ii 


_  ii 
_  ii 
_  it 


ENTER  YOUR  SELECTION  (  1  2  3  4  )  <  4  R  E  P  LY  <77 


_  ii  ii 

-IF  4REPLY  EQ  1  GOTO  ADD  ELSE  IF  4  REPLY  EQ  2  GOTO  ADDUP 
-ELSE  IF  4 REP  LY 

-  EQ  3  GOTO  UP  ELSE  IF  4  REPLY  EQ  4  GOTO  DEL  ELSE 

-  IF  4 RE  PLY  EQ  5  GOTO  EXIT 

-  ELSE  GOTO  NOPE; 

-ADD 

MODIFY  FILE  4FNAME 
CRTFORM 


AUTOMOD  OPTION  //I...  ADD  NEW  RECORDS 


'  TAB  1 
'  F  7  ' 


FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA  " 
FOR  PRIOR  SCREEN  ' F  8 ’  FOR  NEXT  SCREEN  " 
' F 3 '  TO  RETURN  TO  PREVIOUS  MENU 


»» 


CRTFORM 

* 

MATCH  » 

KEYS 

ON  NOMATCH  TYPE 

ii  ii 


" . . . .  RECORD  ACCEPTED 
ON  NOMATCH  INCLUDE 


ENTER  NEXT  RECORD 


ON  MATCH  TYPE 


II  II 

RECORD  ALREADY  EXISTS  ....  REJECTED  ... 
LOG  DU  PL  MSG 
OFF 
DATA 
END 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  LOADING  YOUR  FILE 

-RUN 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  UPDATING  YOUR  FILE 

-GOTO  SECTION  1 

-ADDUP 

MODIFY  FILE  &FNAME 
CRTFORM 

"  AUTOMOD  OPTION  # 2 ADD/ U P D ATE  RECORDS 


"  'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA  " 
"  ' F  7 '  FOR  PRIOR  SCREEN  ' F  8 '  FOR  NEXT  SCREEN  " 
»  'Fi'  TO  RETURN  TO  PREVIOUS  MENU  " 

ti  ti 

it  it 

CRTFORM  » 

KEYS 

"  DEPRESS  ENTER 

ii  ii 

MATCH  * 

KEYS 

ON  MATCH  TYPE  "UPDATING  EXISTING  RECORD  " 

ON  NOMATCH  TYPE  "ADDING  NEW  RECORD" 

ON  MATCH/NOMATCH  CRTFORM  T.*  NONKEYS 
ON  MATCH  UPDATE 

* 

ON  NOMATCH 
INCLUDE 

LOG  NOMATCH  MSG  OFF 

DATA 

END 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  LOADING  YOUR  FILE 
-RUN 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  UPDATING  YOUR  FILE 
-GOTO  SECTION! 

-UP 

MODIFY  FILE  &FNAME 


C  RTFORM 


A'JTOMOD  OPTION  f/j... UPDATE  EXISTING  RECORDS 


TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 
'  F  7  '  FOR  PRIOR  SCREEN  'Fo'FOR  NEXT  SCREEN 
'  F  j  '  TO  RETURN  TO  PREVIOUS  MENU 


CRTFORM 

KEYS 

If 

"  DEPRESS  ENTER 

MATCH  * 

KEYS 

ON  NOMATCH  TYPE 

"  RECORD  DOES  NOT  EXIST ....  ENTER  NEXT  RECORD 
ON  MATCH  TYPE 

"  ENTER  NEW  VALUES  " 


ON  MATCH  CRTFORM  T.» 
NONKEYS 

ON  MATCH  UPDATE 

* 

LOG  NOMATCH  MSG 
OFF 


DATA 

END 

-TYPE 

-TYPE 

-TYPE 

-RUN 

-TYPE 

-TYPE 

-TYPE 


PLEASE  WAIT 


PC/FOCUS  IS  LOADING  YOUR  FILE 


PLEASE  WAIT 


PC/FOCUS  IS  UPDATING  YOUR  FILE 


-GOTO  SECTION  1 
-DEL 

MODIFY  FILE  &FNAME 
CRTFORM 


AUTOMOD  OPTION  // 4  .  .  .  DELETE  EXISTING  RECORDS 

'TAB'  FOR  NEXT  FIELD  'ENTER'  TO  TRANSMIT  DATA 

'FT'  FOR  PRIOR  SCREEN  ' F  3 '  FOR  NEXT  SCREEN 

' F i '  TO  RETURN  TO  PREVIOUS  MENU 


CRTFORM  * 
KEYS 

II  II 

MATCH  * 


•  .  k  .  »  •  •  **  m  _•  .»  >  J  _/S  _>•  ^ 


ON  NOMATCH  TYPE 

It  ft 

" . .  RECORD  DOES  NOT  EXIST  ....  ENTER  NEXT  RECORD 
ON  MATCH  TYPE 

It  It 

" .  RECORD  DELETED 

ON  MATCH 
DELETE 

LOG  NOMATCH  MSG 

OFF 

DATA 

END 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  LOADING  YOUR  FILE 

-RUN 

-TYPE  PLEASE  WAIT 

-TYPE 

-TYPE  PC/FOCUS  IS  UPDATING  YOUR  FILE 

-GOTO 

SECTION  1 

-3ADNAME 

TYPE  INVALID  FILE  NAME  (EXCEEDS  3  CHARACTERS) 

-GOTO 

TOP 

-NOPE 

-TYPE  4REPLY  IS  NOT  A  VALID  OPTION 
-....PLEASE  REVIEW  OPTIONS  AND  RE-ENTER 
-GOTO  SECTION  1 
-NONAME 

-TYPE  FILE  NAMED  &FNAME!  !  .XXX  CANNOT  BE  LOCATED. 
-PROMPT  4REPLY . RE-ENTER  FILE  NAME 

QUIT  . 

-GOTO  SECTION' 

-EXIT 

C.  POWDIC: 

SET  PAUSE  =  OFF 
SET  MSG=OFF 
-TOP 

-CRTCLEAR 

-IF  41. EXIST  EQ  0  GOTO  NONAME; 

-SET  4FNAME=41; 

GOTO  GOTNAME 
-NO  NAME 

-SET  4 F N A M E  =  '  '  ; 

-START 

-TYPE  THIS  IS  THE  AN  ONLINE  HELP  SCREEN 
-CRTFORM 


ONLINE  HELP  SCREEN 


If 


INFORMATION  ON  FOCUS  . <1>  " 

INFORMATION  ON  FOCEXECS  . <2>  " 

DICTIONARY  MAINTENANCE  . <3>  " 

QUIT  . <  4  >  : 

it 

n 

II 


-PROMPT  &SELECT.  WHAT  IS  YOUR  CHOIC  ? 
-END 


D.  POWHELP: 

-CRTCLEAR 

-BEGIN 

-SET  &R£PLAY  =  0  ; 

-TYPE 

-CRTFORM 

_  M  n 

_  it  it 

POW  " 

-"  HELP  SCREEN 


1.  System  Description 

2.  Online  Help 

3 .  Exit 


SELECT  (12  3  )  <  &  R  E  P  LA  Y  <77 


-IF  <i  R E P L A Y  EQ  1  GOTO  SYSDESC 

ELSE  IF  &REPLAY  EQ  2  GOTO  ONLINE 

ELSE  IF  &REPLAY  EQ  3  GOTO  EXIT 

ELSE  GOTO  NOPE; 

-ONLINE 
EX  POWDIC 
-RUN 

-CRTCLEAR 
-GOTO  BEGIN 
-SYSDESC 


•  TYPE 

•GOTO  BEGIN 
■  NOPE 

■GOTO  BEGIN 

■quit 

■EXIT 


»**  WILL  3E  DEVELOPED  1  ATE  R 


V  v- 


Form  Negotiation  Team 


FNT 


Negotiate  Vendors 

V  EGV 

2 . 2 

Contract  Award  Process 

CAW  RD 

2.o 

Prepare  Contract  Draft 

PCD 

2.3.1 

Calculate  Value  of  Contracts 

CVC 

2.0.2 

Check  the  Technical  Terms 

CTT 

2.o.o 

Collect  all  Documents 

CAD 

2  .  o.4 

Final  Review  of  the  Contracts 

FROC 

2.0.3 

Sign  the  Contract 

STC 

2.0.6 

Sign  The  Contract 

SC 

2 . 4 

Fund ing  Contracts 

FC 

0 

Identify  the  Source  of  Fund 

ISOF 

0  .  1 

Process  Fund  From  Budget 

PFFB 

o.2 

Collect  Documents  of  Contracts 

C  DOC 

0.2.1 

Open  Credit  Letter  for  Vendor 

OCRL 

o.2.^ 

Payment  of  Initial  Deposit 

POID 

o.2.o 

Process  Fund  From  Loan 

PFFL 

0  .  0 

Prepare  Request  for  Funding 

From  Loans 

PRFL 

0.0.2 

Payment  Initial  deposit  from 

o  3  n  . 

PIDFL 

3.0.2 

Administer  Contract 

AC 

4 

Payment  Process 

PAYP 

4  .  i 

Register  and  Route  the  Payment 

Documents  to  the  Specialized 

Officer 

RGR 

4.1.1 

1  o  j 
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Check  Payment  Documents 

C.necK  Duplication 

Check  Invoice  Amount 

Monitor  Training  of  Personnel 

Prepare  Training  Plan 

Inform  Vendor  by  Trainee  Names 

Prepare  Status  Reports 

Monitor  Shipment  of  Items 

Prepare  Shipment  Plan 

Compare  and  adjust  Shipment 

Reporting 

Prepare  Status  Reports 
Prepare  Progress  Reports 
Prepare  Comparison  Reports 
Prepare  Analysis  Reports 
Generate  Vendor  List 
Verify  vendors 
Cneck ,  if  Vendor  Exist 


CPDOC 

CHKD 


4.1.2 

4.1.; 


CHKIA 

4.1.4 

MTOP 

4.2 

PTP 

4.2.1 

IVBTN 

4.2.2 

P  SR 

4.2.o 

MS  0  I 

4.  0 

PSHP 

4.0.1 

CADSH 

4.0.2 

REP 

4  .  4 

PSREP 

4.4.1 

PPREP 

4.4.2 

PCREP 

4.4.o 

PAREP 

4.4.4 

GVL 

5 

VERV 

5  .  1 

CHKVE 

5 . 2 

DATA  STORES 
DATA  STORES 

Vendor  list  File 
RFP  Monitor  File 
Contracts  to  be  Funded 
Active  Contracts 


ABBREVIATION  IDENTIFICATION 
VLF  D 1 

RFPMF  D  2 

CTBF  Do 

AC  D  4 


v 


r  < 


Contract  Monitor  File 

CMF 

D  5 

Pending  Proposals  rile 

PPF 

D  6 

General  Log  Book 

G  LB 

D  7 

Thomas  Register 

TREG 

D8 

Pend ing  RFC  File 

PRFCF 

D  9 

Vendor  Meeting  Schedule 

VMS 

DIO 

Final  Reports  Collection 

File 

FRCF 

D  1  1 

Fund  Source  File 

FSF 

D  1 2 

Contracting  Implementation 

Plan 

CIP 

Did 

Officers  Work  Load 

OWL 

D  1  4 

Rules  and  Reflations 

RAREG 

D15 

Best  and  Final  Offer 

3AF0 

D  1  6 

All  Contract's  Document 

File 

AC  DO  C 

D  1  7 

Budget  Monitor  File 

BMF 

Did 

Loans  Monitor  File 

LMF 

D  1  9 

Previous  Payment  Monitor 

File 

PPMF 

D20 

Training  Plan  File 

TP  F 

D2  1 

Shipment  Plan 

SHPF 

D22 

Shipment  Notice  Keeping 

File 

SHNKF 

D2o 

Shipment  Monitor  File 

SHMF 

D  2  4 

Pending  Vendor  Requests 

File 

PVRF 

D2d 

1  bd 


ls_s\ 


-v 


/  / 


DATA  FLOWS 


DATA  FLOWS 
RFP 
»  \ 

r  i 

i  i 

t  » 

t  t 

i  i 

RFP  Subject  &  date  received 

t  t 

RFP  Subject  &  Department 

f  I 

Mew  Vendor  Name 
Proposals 

Vendor  list  with  RFP’s 

I  » 

Proposals 


1  O  D 


IDENTIFICATION 

a-  1 
a  -  1  .  1 
a-  1  .  1  .  1 
1 . 1 . 1-1 . 1 .2 
1  .  1 . 2-1  .  1  .  o 

1 . 1 . o-  1  .  1  .  4 

1.1.  4-b 

1 . 1 . 1- D? 

1.2. 1 - D6 
D2-1 .l.o 
1  .  1  .  2-D2 

1  .  1  . 3-1  ■  1  . 5 


1  -a 


1  -b 


b-1 
b-  1  .  2 
1 . 2-D  b 

Db-  1  .  j 

1  .  3-d 
d- 1  . 2  .  1 
1  .  2  .  1  -  1  .  2  .  2 
1  .  2 . 2  -  1  .  2  .  o 

D  6  -  1  .  2  .  o 


Proposals 


1  .  2  .  5  —  a 


Number  of  Proposals  &  Vendors 
Vendor  data 
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